Άρθρο 25 Απαιτήσεις του ενδιάμεσου συστήματος ελέγχου για το διαδικτυακό παιγνιο – Γενική Αρχιτεκτονική

25.1 Τοπολογία του συστήματος

Όσον αφορά στη γενική αρχιτεκτονική του συστήματος, αυτή συνδυάζει 5 διαφορετικά συστήματα, τα οποία αναφέρονται παρακάτω και αναλύονται στην παρούσα ενότητα. Τα κύρια συστήματα που απαρτίζουν τη συνολική αρχιτεκτονική είναι:

  • Η διεπαφή παίκτη.
  • Η πύλη ελέγχου σε πραγματικό χρόνο (Gateway).
  • Η κεντρική πλατφόρμα παρόχου υπηρεσιών τυχερών παιγνίων.
  • Το ενδιάμεσο σύστημα ελέγχου.
  • Η υποδομή της Αρχής.

Σχηματικά, η τοπολογία του συστήματος παρουσιάζεται στην εικόνα που ακολουθεί.

Εικόνα 1. Τοπολογία τεχνικής λύσης

Ο πάροχος υπηρεσιών τυχερών παιγνίων μέσω διαδικτύου έχει την υποχρέωση να υλοποιήσει το ενδιάμεσο σύστημα ελέγχου και την πύλη ελέγχου σε πραγματικό χρόνο (Gateway), σύμφωνα με τις προδιαγραφές που παρουσιάζονται στη συνέχεια.

Το ενδιάμεσο σύστημα ελέγχου έχει σαν κύριες λειτουργίες τη συλλογή των δεδομένων από την κεντρική πλατφόρμα του παρόχου (data capture), την ασφάλεια των δεδομένων αυτών (ακεραιότητα, αυθεντικότητα, εμπιστευτικότητα, διαθεσιμότητα) (data sealing) και την οριστική αποθήκευσή τους στη διάταξη ασφαλούς αποθήκευσης (Safe).

Μέσω της πύλης ελέγχου σε πραγματικό χρόνο, όλη η διαδικτυακή κίνηση των παικτών κατευθύνεται στην κεντρική πλατφόρμα του παρόχου.

Η Αρχή έχει πρόσβαση στη διάταξη ασφαλούς αποθήκευσης, προκειμένου να προσπελάσει τα δομημένα σύνολα δεδομένων που απαιτούνται για τον ελεγκτικό και εποπτικό της ρόλο.

Στη συνέχεια περιγράφονται αναλυτικά οι τεχνικές προδιαγραφές των παραπάνω συστημάτων, δίνοντας μεγαλύτερη έμφαση στα υποσυστήματα του ενδιάμεσου συστήματος ελέγχου και στην πύλη ελέγχου σε πραγματικό χρόνο (Gateway).

25.2 Προέλευση δεδομένων (data capture)

Όπως έχει αναφερθεί, ο πάροχος έχει την υποχρέωση να υλοποιήσει στο ενδιάμεσο σύστημα ελέγχου, το υποσύστημα data capture, το οποίο εκτελεί τις παρακάτω λειτουργίες:

  • Εξάγει δεδομένα από την κεντρική πλατφόρμα του παρόχου.
  • Τα μετασχηματίζει στη μορφή που καλύπτει τις προδιαγραφές που τίθεται από την Αρχή (μοντέλα δεδομένων).
  • Τα μεταφέρει προς αποθήκευση (αφού πρώτα εκτελέσει λειτουργίες για την ασφάλειά τους) στη διάταξη ασφαλούς αποθήκευσης (Safe).

25.2.1 Μορφή των δεδομένων

Η ενδεδειγμένη μορφή ανταλλαγής δεδομένων μεταξύ της Αρχής και παρόχου είναι η αποστολή δεδομένων μέσω αρχείων XML (eXtensible Markup Language). Η γλώσσα XML αποτελεί σήμερα ένα ευρέως διαδεδομένο και ανοικτό πρότυπο για την περιγραφή και ανταλλαγή δεδομένων. Η XML έχει αναπτυχθεί και συντηρείται από το W3C (World Wide Web Consortium).

Μέσω της χρήσης της γλώσσας XML για την ανταλλαγή των δεδομένων εξασφαλίζεται η ελεγχόμενη, ασφαλής και γρήγορη ροή δεδομένων, μεταξύ των δύο μερών. Ταυτόχρονα, η χρήση ενός διεθνούς και ανοικτού προτύπου, όπως η είναι η γλώσσα XML, συμβάλει στην ενίσχυση της διαλειτουργικότητας σε επίπεδο πληροφοριακών συστημάτων, μεταξύ κυβερνητικών οργανισμών και επιχειρήσεων, όπως περιγράφεται και στο Ελληνικό Πλαίσιο Παροχής Υπηρεσιών Ηλεκτρονικής Διακυβέρνησης (Greek eGIF).

Κατά το μετασχηματισμό των δεδομένων που εξάγονται από την κεντρική πλατφόρμα του παρόχου, ο πάροχος οφείλει να ακολουθεί τις οδηγίες που περιγράφονται στο εκάστοτε μοντέλο δεδομένων που ορίζει η Αρχή. Τα μοντέλα δεδομένων περιγράφονται από αντίστοιχα σχήματα XML (XML schemas). Πριν τα δεδομένα αποθηκευτούν και σφραγιστούν στη διάταξη ασφαλούς αποθήκευσης (Safe), πιστοποιούνται ως προς τη συμβατότητά τους με το μοντέλο δεδομένων, που ορίζει η Αρχή (validate XML against XSD). Τα αρχεία XSD θα είναι διαθέσιμα στους ενδιαφερόμενους μέσω του διαδικτυακού τόπου της Αρχής (https://www.gamingcommission.gov.gr).

Τα δεδομένα ακολουθούν την κωδικοποίηση UTF-8, ενώ όπου γίνεται αναφορά σε χρόνο, ακολουθείται το πρότυπο UTC.

25.2.2 Μέγιστη καθυστέρηση

Η μέγιστη καθυστέρηση μεταξύ του εκάστοτε γεγονότος και του χρόνου εισαγωγής του στο Safe είναι δύο (2) ώρες. Συνεπώς, τα δεδομένα πρέπει να μεταφέρονται στη διάταξη ασφαλούς αποθήκευσης (Safe) το αργότερο κάθε δύο (2) ώρες.

25.2.3 Χωροθέτηση υποσυστήματος data capture

Το υποσύστημα data capture μπορεί να φιλοξενείται εντός ΕΕ ή ΕΟΧ, αρκεί να πληρούνται οι προδιαγραφές που θέτει η Αρχή.

To data center που φιλοξενεί το υποσύστημα data sealing πρέπει να πληροί τις προδιαγραφές που περιγράφονται στο κεφάλαιο Ασφάλεια Υποδομών IT.

25.3 Κλείδωμα των δεδομένων (data sealing)

25.3.1 Διαδικασία κλειδώματος των δεδομένων

Στην ενότητα αυτή παρουσιάζεται αναλυτικά η διαδικασία κλειδώματος των δεδομένων, προκειμένου να διασφαλιστεί η ακεραιότητά και αυθεντικότητά τους. Ειδικότερα, η διαδικασία του κλειδώματος περιλαμβάνει μια σειρά βημάτων, τα οποία έχουν ως εξής:

  • Βήμα 1: Δημιουργία πακέτων δεδομένων (batching) αποτελούμενων από έναν αριθμό εγγραφών, όπως περιγράφεται αναλυτικά στις ενότητες που ακολουθούν.
  • Βήμα 2: Σύνδεση του τρέχοντος πακέτου δεδομένων με το αμέσως προηγούμενο (chaining), μέσω της συμπερίληψης στο τρέχον πακέτο μιας τιμής (SHA-256) του προηγούμενου πακέτου και δημιουργία μιας «αλυσίδας» πακέτων δεδομένων.
  • Βήμα 3: Ψηφιακή υπογραφή των πακέτων δεδομένων.
  • Βήμα 4: Συμπίεση δεδομένων με τον αλγόριθμο «deflate» (RFC1951).
  • Βήμα 5: Χρονοσήμανση των συμπιεσμένων δεδομένων σύμφωνα με το πρότυπο XAdES-T.
  • Βήμα 6: Τα συμπιεσμένα δεδομένα κρυπτογραφούνται με συμμετρικό, τυχαία παραγόμενο κλειδί, μιας χρήσης, της τρέχουσας συνόδου (AES-256).
  • Βήμα 7: Το κλειδί συνόδου είναι κρυπτογραφημένο με το δημόσιο κλειδί της Αρχής (RSA-2048).
  • Βήμα 8: Τα δεδομένα (από το βήμα 1.), η χρονοσήμανση (από το βήμα 5.) και το κρυπτογραφημένο κλειδί (από το βήμα 6.), δημιουργούν ένα νέο αρχείο zip, το οποίο αποθηκεύεται οριστικά στο Safe.
25.3.1.1 Batching – Πακέτα δεδομένων

Η μέγιστη καθυστέρηση μεταξύ του εκάστοτε γεγονότος και του χρόνου εισαγωγής του στο Safe είναι δύο (2) ώρες. Συνεπώς, τα δεδομένα πρέπει να μεταφέρονται στη διάταξη ασφαλούς αποθήκευσης (Safe) το αργότερο κάθε δύο (2) ώρες.

Τα δεδομένα εισάγονται στο Safe με τη μορφή πακέτων δεδομένων (batch). Σε κάθε πακέτο δεδομένων υπάρχει μόνο ένα αρχείο xml, για κάθε μοντέλο δεδομένων. Σε περίπτωση που πρέπει να αποσταλούν αρχεία xml που ανήκουν σε διαφορετικό μοντέλο δεδομένων, τότε δημιουργούνται τόσο πακέτα δεδομένων, όσα είναι και τα διαφορετικά μοντέλα δεδομένων. Το πακέτο δεδομένων φέρει ειδική χρονοσήμανση, όπως περιγράφεται στην παράγραφο 25.3.1.5.

Το πακέτο δεδομένων δημιουργείται στις ακόλουθες περιπτώσεις:

  • Κάθε δύο (2) ώρες,
  • ή όταν το μέγεθος της συμπιεσμένης πληροφορίας ξεπερνά τα 200MB,
  • στο τέλος κάθε ημέρας (00:00 UTC).

Αν παρέλθει χρονικό διάστημα δύο (2) ωρών χωρίς να υπάρξει κάποια εγγραφή, τότε δημιουργείται ένα κενό πακέτο δεδομένων. Σε ένα κενό πακέτο δεδομένων δεν υπάρχει αρχείο δεδομένων xml, αλλά μόνο το αρχείο που περιέχουν τις πληροφορίες ελέγχου του συγκεκριμένου πακέτου.

25.3.1.2 Chaining

Προκειμένου να εξασφαλιστεί ο μέγιστος βαθμός ασφάλειας στην αποθήκευση και διατήρηση των δεδομένων στη διάταξη ασφαλούς αποθήκευσης δεδομένων, χρησιμοποιούνται τεχνικές σύνδεσης των διαδοχικών πακέτων δεδομένων (chaining), πριν αυτά αποθηκευτούν οριστικά σε αυτή.

Επιπλέον, η διαδικασία του chaining ενισχύει την ακεραιότητα και την αυθεντικότητα των καταγεγραμμένων δεδομένων, ενώ συνάμα εξασφαλίζει τη συνοχή τους.

Μέσω της διαδικασίας αυτής, η Αρχή είναι σε θέση να εντοπίσει τυχόν διαγραφή ή τροποποίηση των αρχειοθετημένων δεδομένων, ανεξάρτητα από το αν αυτό έχει γίνει από κακόβουλη ενέργεια ή όχι.

Μετά τη δημιουργία του τρέχοντος πακέτου δεδομένων, αυτό συνδέεται με το αμέσως προηγούμενο πακέτο δεδομένων, μέσω της συμπερίληψης μιας hash τιμής (SHA-256) στο τρέχον πακέτο (cryptographic linking). Ο τρόπος αναφοράς των τιμών hash των προηγούμενων πακέτων δημιουργεί μια «αλυσίδα» πακέτων δεδομένων, όπως παρουσιάζεται στην εικόνα που ακολουθεί.

Εικόνα 2. Διαδικασία σύνδεσης διαδοχικών πακέτων δεδομένων (chaining)

 

25.3.1.3 Ψηφιακή υπογραφή δεδομένων

Τα πακέτα δεδομένων που εισάγονται στο ασφαλές σύστημα αποθήκευσης πρέπει να φέρουν ψηφιακή υπογραφή, ώστε να διασφαλίζεται η ακεραιότητα και η αυθεντικότητά τους. Η ψηφιακή υπογραφή πρέπει να ακολουθεί το πρότυπο XAdES (ETSI TS 101 933), το οποίο είναι διεθνώς διαδεδομένο πρότυπο που χρησιμοποιείται για την ψηφιακή υπογραφή αρχείων τύπου XML.

Το πρότυπο XAdES ενσωματώνει επιπλέον χαρακτηριστικά ασφάλειας στις ψηφιακές υπογραφές, συνδυάζοντάς τις με χρονοσημάνσεις, ενώ υλοποιεί επίσης το κρυπτογραφικό “δέσιμο” της υπογραφής με μια πολιτική υπογραφής που εδραιώνει τη νομική της αξία, καλύπτοντας την απαίτηση για μη άρνηση της ευθύνης.

Κάθε πάροχος οφείλει να διαθέτει το δικό του κλειδί ψηφιακής υπογραφής.

25.3.1.4 Συμπίεση και Κρυπτογράφηση δεδομένων

Τα πακέτα δεδομένων συμπιέζονται με τον αλγόριθμο «deflate» (RFC1951), προκειμένου να μειωθεί ο όγκος των αποθηκευμένων δεδομένων στη διάταξη ασφαλούς αποθήκευσης (Safe).

Στη συνέχεια, το συμπιεσμένο πακέτο δεδομένων κρυπτογραφείται για να διασφαλιστεί η εμπιστευτικότητα χρησιμοποιώντας μια διαδικασία δύο βημάτων:

  1. Αρχικά, η διάταξη ασφαλούς αποθήκευσης (Safe) θα πρέπει να δημιουργεί δυναμικά ένα συμμετρικό κλειδί (256 bit), για κάθε πακέτο δεδομένων, προκειμένου να το κρυπτογραφήσει, χρησιμοποιώντας το πρότυπο Advanced Encryption Standard (AES256).
  2. Στη συνέχεια, το παραγόμενο κλειδί AES256 κρυπτογραφείται ασυμμετρικά με τα δημόσια κλειδιά της Αρχής (πιστοποιητικό X.509), σύμφωνα με τη διαδικασία RSA2048 (2048 -bit RSA keys).

Σχηματικά, η παραπάνω διαδικασία παρουσιάζεται στην εικόνα που ακολουθεί.

 

Εικόνα 3. Διαδικασία συμπίεσης και κρυπτογράφησης των δεδομένων

 

Στο δεύτερο βήμα πρέπει να παρέχεται η δυνατότητα ασυμμετρικής κρυπτογράφησης με περισσότερα του ενός δημόσια κλειδιά (πιστοποιητικά Χ.509), εφόσον αυτό ζητηθεί από την Αρχή.

Το ψηφιακό πιστοποιητικό το οποίο χρησιμοποιείται στην ανωτέρω διαδικασία δύναται να αντικαθίστανται με απόφαση της Αρχής.

25.3.1.5 Χρονοσήμανση δεδομένων

Είναι απαραίτητη η χρονοσήμανση των δεδομένων, ώστε να εξασφαλίζεται η ακεραιότητά τους και να συνδέονται τα δεδομένα με συγκεκριμένη χρονική στιγμή. Η χρονοσήμανση θα προστίθεται με τη μορφή ψηφιακής υπογραφής στο κάθε batch. Οι παραπάνω ψηφιακές υπογραφές θα πρέπει να μπορούν να υποστηρίξουν Timestamps από οποιονδήποτε Timestamp Server συμβατό με το ευρωπαϊκό πρότυπο eIDAS time-stamps ETSI EN 319 422 (RFC 3161). Τέλος, οι ψηφιακές υπογραφές χρονοσήμανσης θα πρέπει να είναι συμβατές με το πρότυπο XAdES-T.

25.3.2 Διασύνδεση του υποσυστήματος data sealing με το Safe

Η διασύνδεση του υποσυστήματος data sealing με το Safe γίνεται μέσω μιας ασφαλούς σύνδεσης εικονικού ιδιωτικού δικτύου (VPN), από άκρο σε άκρο.

25.3.3 Χωροθέτηση υποσυστήματος data sealing

Το υποσύστημα data capture μπορεί να φιλοξενείται εντός ΕΕ ή ΕΟΧ, αρκεί να πληρούνται οι προδιαγραφές που θέτει η Αρχή.

To data center που φιλοξενεί το υποσύστημα data sealing πρέπει να πληροί τις προδιαγραφές που περιγράφονται στο κεφάλαιο Ασφάλεια Υποδομών IT.

 

25.4 Αποθήκευση των δεδομένων

25.4.1 Τεχνικές προδιαγραφές διάταξης ασφαλούς αποθήκευσης δεδομένων

Ο πάροχος υπηρεσιών τυχερών παιγνίων μέσω διαδικτύου υποχρεούται να αποθηκεύει σε υλικό μηχανισμό (διάταξη ασφαλούς αποθήκευσης δεδομένων) τα δεδομένα που αφορούν στη διεξαγωγή τυχερών παιγνίων μέσω διαδικτύου, καθώς και τα δεδομένα που ανταλλάσσονται μεταξύ παίκτη, παρόχου υπηρεσιών διαδικτύου και χρηματοπιστωτικών ιδρυμάτων, σχετικά με τα παίγνια αυτά.

Οι ελάχιστες τεχνικές απαιτήσεις της διάταξης ασφαλούς αποθήκευσης δεδομένων παρουσιάζονται παρακάτω:

  1. Η διάταξη ασφαλούς αποθήκευσης δεδομένων (Safe) πρέπει να λειτουργεί σαν αυτόνομη υποδομή, η οποία είναι φυσικά διαχωρισμένη από την κεντρική πλατφόρμα του παρόχου υπηρεσιών τυχερών παιγνίων.
  2. Δεν επιτρέπεται η αποθήκευση δεδομένων στο Safe, εκτός των μοντελοποιημένων δεδομένων που ορίζει η Αρχή.
  3. Ο Κάτοχος Αδείας πρέπει να εξασφαλίσει τη δημιουργία αντιγράφων ασφαλείας όλων των δεδομένων, σύμφωνα με τα οριζόμενα στην σχετική ενότητα. Η διάταξη ασφαλούς αποθήκευσης δεδομένων και ο εναλλακτικός χώρος αποθήκευσης των αντιγράφων ασφαλείας πρέπει να διαχωρίζονται γεωγραφικά, σύμφωνα με τα οριζόμενα στην σχετική ενότητα. Επιπλέον, η αποθήκευση δεδομένων σε δευτερεύοντα αποθηκευτικά μέσα (offline δεδομένα), όπως ορίζεται στην σχετική ενότητα, δε μπορεί να γίνεται στην ίδια γεωγραφική περιοχή που φιλοξενείται το αντίγραφο ασφαλείας του Safe (εναλλακτικός χώρος αποθήκευσης των αντιγράφων ασφαλείας).
  4. Η πιστοποίηση που φέρει το Safe θα πρέπει να εντάσσεται στην πιστοποίηση του πληροφοριακού συστήματος του παρόχου τυχερών παιχνιδιών στο διαδίκτυο.
  5. Ο Κάτοχος Άδειας πρέπει να εξασφαλίσει ότι η Αρχή θα έχει ασφαλή πρόσβαση τόσο στη διάταξη ασφαλούς αποθήκευσης των δεδομένων (Safe), όσο και στον εναλλακτικό χώρο αποθήκευσης, σύμφωνα με τα οριζόμενα στην σχετική ενότητα.
  6. Στη διάταξη ασφαλούς αποθήκευσης δεδομένων, τα δεδομένα πρέπει να αποθηκεύονται ακολουθώντας την ονοματολογία και τη δομή αρχείων/φακέλων που καθορίζεται από την Αρχή, σύμφωνα με τα οριζόμενα στην σχετική ενότητα.
  7. Τα δεδομένα που είναι αποθηκευμένα στο Safe πρέπει να ακολουθούν τα μοντέλα δεδομένων και τις καθορισμένες πρότυπες αναφορές που έχουν οριστεί από την Αρχή.
  8. Τα δεδομένα που είναι αποθηκευμένα στο Safe πρέπει να είναι συμπιεσμένα και κρυπτογραφημένα, σύμφωνα με τα οριζόμενα στην σχετική ενότητα, ώστε μόνο η Αρχή να έχει πρόσβαση σε αυτά.
  9. Οι Κάτοχοι Άδειας πρέπει να πιστοποιούν και να τεκμηριώνουν ότι το ενδιάμεσο σύστημα ελέγχου και η πύλη ελέγχου σε πραγματικό χρόνο (Gateway) συμμορφώνονται με τις απαιτήσεις που ορίζονται στο παρόν τεχνικό εγχειρίδιο.
  10. Το Safe πρέπει να είναι διαθέσιμο 24/7, 365 ημέρες το χρόνο, με εγγυημένη διαθεσιμότητα τουλάχιστον 99,95%.
  11. Οι Κάτοχοι Αδειών είναι υπεύθυνοι για τη λειτουργία του Safe, του ενδιάμεσου συστήματος ελέγχου και της πύλη ελέγχου σε πραγματικό χρόνο (Gateway).
  12. Ο Κάτοχος της Άδειας πρέπει να εξασφαλίσει πρόσβαση στο Safe για την Αρχή, ώστε να είναι δυνατή η ακόλουθη σύνδεση: Η Αρχή πρέπει να έχει τη δυνατότητα πρόσβασης στο Safe μέσω μιας FTPS (FTP over SSL) σύνδεσης. Αναλυτικά οι προδιαγραφές της πρόσβασης της Αρχής στα δεδομένα περιγράφονται στη σχετική ενότητα.
  13. Η πρόσβαση στα δεδομένα που περιλαμβάνονται τόσο στο Safe, όσο και στον εναλλακτικό χώρο αποθήκευσης γίνεται μόνο από προκαθορισμένες IP διευθύνσεις που κοινοποιούνται στον πάροχο από την Αρχή.
  14. Ο Κάτοχος Άδειας οφείλει να τηρεί τις προδιαγραφές που αφορούν τις εργασίες συντήρησης και τα έκτακτα περιστατικά των υποδομών του ενδιάμεσου συστήματος και της πύλης Gateway.
  15. Ο Κάτοχος Άδειας οφείλει σε περίπτωση που εντοπιστεί από την Αρχή πρόβλημα μη συμμόρφωσης των δεδομένων με τα μοντέλα που έχουν οριστεί, να ανταποκριθεί αμελλητί στη διόρθωσή και εκ νέου υποβολή τους. Η επικοινωνία μεταξύ Αρχής και Κατόχου Άδειας γίνεται σύμφωνα με τα οριζόμενα στη σχετική ενότητα.
  16. Η Αρχή θα πρέπει να έχει φυσική πρόσβαση στους χώρους που φιλοξενούνται το Safe και η πύλη (Gateway), με δυνατότητες περιήγησης στο σύστημα αρχείων του Safe και αντιγραφής των δεδομένων του Safe σε αποσπώμενο μέσο αποθήκευσης.

25.4.2 Χωροθέτηση διάταξης ασφαλούς αποθήκευσης δεδομένων

Ο πάροχος οφείλει για φιλοξενεί τη διάταξη ασφαλούς αποθήκευσης δεδομένων εντός ελληνικής επικράτειας.

To data center που φιλοξενεί την υποδομή Safe πρέπει να πληροί τις προδιαγραφές που περιγράφονται στο κεφάλαιο Ασφάλεια Υποδομών IT.

25.4.3 Διαχωρισμός των δεδομένων

Τα δεδομένα που αποθηκεύονται στο Safe πρέπει να πληρούν τις τεχνικές προδιαγραφές που θέτει η Αρχή. Δεν επιτρέπεται η αποθήκευση δεδομένων στο Safe, εκτός των μοντελοποιημένων δεδομένων που ορίζονται από την Αρχή.

25.4.4 Μορφή αποθηκευμένων δεδομένων στη διάταξη ασφαλούς αποθήκευσης

Μετά τη διαδικασία κλειδώματος των δεδομένων που έχει περιγραφεί σε προηγούμενη ενότητα, τα συμπιεσμένα και κρυπτογραφημένα δεδομένα αποθηκεύονται στο Safe.

Κάθε πακέτο δεδομένων που αποθηκεύεται στο Safe περιλαμβάνει την εξής πληροφορία:

  1. Το συμπιεσμένο και κρυπτογραφημένο πακέτο δεδομένων (περιλαμβάνει τις εγγραφές στη μορφή xml). Το αρχείο αυτό θα έχει πάντα την ονομασία data.bin.
  2. Την απαραίτητη πληροφορία ελέγχου (control manifest) (περιγράφεται αναλυτικά στην σχετική ενότητα).

Η παραπάνω πληροφορία αποθηκεύεται με τη μορφή zip στο Safe. Το τελικό αρχείο zip αρχειοθετείται στο Safe στη δομή φακέλων της αντίστοιχης ημέρας. Το όνομα του τελικού αρχείου σχηματίζεται σύμφωνα με το ακόλουθο πρότυπο:

<licenseholder>_<licenseid>_<seqno>_<YYYYMMDD>_<hhmmss>.zip

Όπου:

  • <licenseholder>: Όνομα του Κατόχου της Άδειας (πεζοί χαρακτήρες).
  • <licenseid>: Αναγνωριστικό του τύπου άδειας του παρόχου.
  • <seqno>: Αύξων αριθμός πακέτου δεδομένων, ανά licenseid (10 αριθμητικά ψηφία – leading zeros).
  • <YYYYMMDD>:Ημερομηνία δημιουργίας.
  • <hhmmss>: Ώρα δημιουργίας (24ωρη βάση).

25.4.5 Δομή και ονοματολογία πακέτων δεδομένων στη διάταξη ασφαλούς αποθήκευσης

Στη διάταξη ασφαλούς αποθήκευσης δεδομένων, τα τελικά πακέτα δεδομένων πρέπει να αποθηκεύονται ακολουθώντας την παρακάτω δενδρική δομή αρχείων/φακέλων και συγκεκριμένη ονοματολογία:

  • LICENSEHOLDER
    • L1
      • YYYY
        • MM
          • o DD
            • <LICENSEHOLDER>_<L1>_0000000001_<YYYYMMDD>_<hhmmss>.zip
            • <LICENSEHOLDER>_<L1>_0000000002_<YYYYMMDD>_<hhmmss>.zip
            • <LICENSEHOLDER>_<L1>_0000000003_<YYYYMMDD>_<hhmmss>.zip
            • <LICENSEHOLDER>_<L1>_000000000N_<YYYYMMDD>_<hhmmss>.zip
      • YYYY
        • MM
          • o DD
            • <LICENSEHOLDER>_<L1>_Ν+1_<YYYYMMDD>_<hhmmss>.zip
            • <LICENSEHOLDER>_<L1>_Ν+2_<YYYYMMDD>_<hhmmss>.zip
            • <LICENSEHOLDER>_<L1>_Ν+3_<YYYYMMDD>_<hhmmss>.zip
    • L2
      • YYYY
        • MM
          • o DD
            • <LICENSEHOLDER>_<L2>_0000000001_<YYYYMMDD>_<hhmmss>.zip
            • <LICENSEHOLDER>_<L2>_0000000002_<YYYYMMDD>_<hhmmss>.zip
            • <LICENSEHOLDER>_<L2>_0000000003_<YYYYMMDD>_<hhmmss>.zip
            • <LICENSEHOLDER>_<L2>_000000000N_<YYYYMMDD>_<hhmmss>.zip

25.4.6 Διαθεσιμότητα παροχής υπηρεσιών

Η διαθεσιμότητα της διάταξης ασφαλούς αποθήκευσης δεδομένων, των λοιπών υποσυστημάτων του ενδιάμεσου συστήματος ελέγχου και της πύλης (Gateway), πρέπει να είναι τουλάχιστον 99,95%. Ο πάροχος οφείλει να τεκμηριώσει στην Αρχή τη διατήρηση της διαθεσιμότητα του συστήματος στο ποσοστό αυτό, παρέχοντας σχετικό πλάνο διαστασιολόγησης των προαναφερθέντων συστημάτων.

Σε περίπτωση βλάβης κάποιου υποσυστήματος (data capture ή/και data sealing) πρέπει τα δεδομένα που δεν έχουν παραληφθεί ακόμη από το υποσύστημα ασφαλούς αποθήκευσης, να παραληφθούν άμεσα μετά την εκ νέου έναρξη της ορθής λειτουργίας τους, έτσι ώστε τα δεδομένα να είναι ανελλιπή δομικά και χρονικά.

Επιπλέον, ο πάροχος καλείται να παρέχει εναλλακτικό πλάνο συνέχισης της παροχής των υπηρεσιών προς την Αρχή.

25.4.7 Διατήρηση των δεδομένων

Τα δεδομένα πρέπει να διατηρούνται στο Safe για χρονικό διάστημα δέκα (10) έτη.

Συγκεκριμένα, τα δεδομένα πρέπει να είναι διαθέσιμα online (άμεσα προσπελάσιμα) στην Αρχή, μέσω της διάταξης ασφαλούς αποθήκευσης, για τα πρώτα πέντε (5) έτη. Ακολούθως, τα δεδομένα μπορούν για ακόμη πέντε (5) έτη, να είναι αρχειοθετημένα σε δευτερεύοντα αποθηκευτικά μέσα (offline δεδομένα). Τα offline δεδομένα, πρέπει να διατηρούνται εντός του ενδιάμεσου συστήματος ελέγχου και εντός ελληνικής επικράτειας. Σε κάθε περίπτωση, η φιλοξενία των offline δεδομένων δε μπορεί να γίνεται στην ίδια γεωγραφική περιοχή που φιλοξενείται το αντίγραφο ασφαλείας του Safe (εναλλακτικός χώρος αποθήκευσης των αντιγράφων ασφαλείας).

Το αργότερο σε δύο (2) ημερολογιακές ημέρες πρέπει τα offline δεδομένα να μπορούν να είναι άμεσα προσπελάσιμα από την Αρχή, μέσω της διάταξης ασφαλούς αποθήκευσης.

Μετά το πέρας των δέκα 10 ετών πρέπει τα δεδομένα να διαγράφονται, χωρίς δυνατότητα ανάκλησης.

25.4.8 Αντίγραφα ασφαλείας

Τα δεδομένα στη διάταξη ασφαλούς αποθήκευσης δεδομένων πρέπει να αντιγράφονται με ασφάλεια σε έναν εναλλακτικό αποθηκευτικό χώρο, ώστε να μην υπάρχει απώλεια δεδομένων, σε περίπτωση ενός σοβαρού περιστατικού καταστροφής του κύριου αποθηκευτικού χώρου.

Ο εναλλακτικός χώρος αποθήκευσης θα πρέπει να βρίσκεται σε απόσταση τουλάχιστον 30 χιλιομέτρων από την κύρια διάταξη ασφαλούς αποθήκευσης και να συγχρονίζεται με αυτή κάθε 30 λεπτά, με μια ασφαλή σύνδεση αφιερωμένη αποκλειστικά για το σκοπό αυτό. Στον εναλλακτικό χώρο αποθήκευσης θα πρέπει να διαθέτει διαβαθμισμένη απομακρυσμένη πρόσβαση και η Αρχή (όπως περιγράφεται και στη σχετική ενότητα).

To data center που φιλοξενεί την υποδομή του εναλλακτικού χώρου αποθήκευσης πρέπει να βρίσκεται εντός ΕΕ ή ΕΟΧ και να πληροί τις προδιαγραφές που περιγράφονται στο κεφάλαιο Ασφάλεια Υποδομών IT.

Σε περίπτωση ενός σοβαρού περιστατικού καταστροφής του κύριου αποθηκευτικού χώρου, το χρονικό διάστημα επαναφοράς του σε πλήρη λειτουργία, με όλα τα δεδομένα, όπως ήταν στην προτέρα κατάστασή του, δε μπορεί να ξεπερνά τις πέντε (5) ημερολογιακές ημέρες.

Σε μια τέτοια περίπτωση ο πάροχος οφείλει να ενημερώσει αμελλητί την Αρχή για το συμβάν, να τεκμηριώσει λεπτομερώς τα αίτια του συμβάντος και να καταθέσει πλάνο για την επαναφορά της υποδομής στην προτέρα κατάσταση.

Για την έναρξη της επαναφοράς των δεδομένων από τον εναλλακτικό χώρο αποθήκευσης στον κύριο, απαιτείται η έγκριση της Αρχής.

25.4.9 Εγκατάσταση πειραματικού λογαριασμού παιχνιδιού για την Αρχή

Ο πάροχος πρέπει να δημιουργήσει για την Αρχή έναν πειραματικό λογαριασμό παιχνιδιού, ο οποίος καθιστά δυνατή τη συμμετοχή στο παιχνίδι κάτω από πραγματικές συνθήκες, εξαιρουμένων των δυνατοτήτων της κατάθεσης χρημάτων και πληρωμής.

Όλες οι δραστηριότητες του πειραματικού λογαριασμού παιχνιδιού πρέπει, όπως τα δεδομένα των πραγματικών παικτών, να καταγράφονται στη διάταξη ασφαλούς αποθήκευσης δεδομένων.

25.4.10 Διόρθωση δεδομένων / Ακύρωση εγγραφής

Όταν απαιτείται η διόρθωση δεδομένων που έχουν ήδη αποσταλεί προς μόνιμη αποθήκευση στη διάταξη ασφαλούς αποθήκευσης (Safe), τότε ο πάροχος αποστέλλει τη νέα εγγραφή διατηρώντας αναφορά στην εγγραφή προς αντικατάσταση. Ειδικότερα:

  • Δημιουργείται μια νέα πλήρης εγγραφή, με το σύνολο των δεδομένων που υπάρχουν στην προς αντικατάσταση εγγραφή και με ειδική αναφορά στην αρχική καταγεγραμμένη εγγραφή (previous record id).
  • Στην περίπτωση που πρέπει να γίνει ακύρωση μιας εγγραφής, δε δημιουργείται μια πλήρης κενή εγγραφή όπως παραπάνω, αλλά γίνεται χρήση ειδικού μοντέλου δεδομένων για το σκοπό αυτό. Για κάθε ακύρωση εγγραφής απαιτείται επαρκή αιτιολόγηση της ενέργειας και χρονοσήμανσή της.

25.4.11 Κατ’ απαίτηση αποστολή δεδομένων

Η Αρχή μπορεί να ζητά από τον Κάτοχο της Άδειας συμπληρωματικά δεδομένα, εφόσον κρίνεται σκόπιμο. Σε περίπτωση που το μοντέλο των δεδομένων που ζητούνται από την Aρχή, δε συμπεριλαμβάνεται στη λίστα με τα διαθέσιμα μοντέλα δεδομένων, η Aρχή οφείλει να αποστέλλει στον Κάτοχο της Άδειας και το σχετικό μοντέλο δεδομένων.

Η διαδικασία αποθήκευσης του νέου πακέτου δεδομένων στη διάταξη ασφαλούς αποθήκευσης θα ακολουθεί την ίδια διαδικασία που ισχύει για όλα τα πακέτα δεδομένων, όπως έχει περιγραφεί σε προηγούμενη ενότητα.

Τα αρχεία που αποθηκεύονται στη διάταξη ασφαλούς αποθήκευσης θα πρέπει να φέρουν το χαρακτηριστικό αναγνωριστικό «_od_» στην ονομασία τους, στη συνέχεια του αναγνωριστικού <licenceid>, ώστε να διασφαλιστεί η αναγνώρισή τους ως «κατ’ απαίτηση δεδομένα».

Παράδειγμα:

<LICENSEHOLDER>_<licenceid>_od_000000000Ν_<20180101>_<13:00:00>.zip

 

25.5 Πύλη ελέγχου σε πραγματικό χρόνο (Gateway)

Μέσω της πύλης ελέγχου σε πραγματικό χρόνο, όλη η διαδικτυακή κίνηση των παικτών κατευθύνεται στην κεντρική πλατφόρμα του παρόχου.

Τα τυχερά παίγνια διεξάγονται μέσω ιστοτόπων που έχουν υποχρεωτικά ονομασία χώρου (Domain name) με κατάληξη .gr. Έτσι, η πρόσβαση στις υπηρεσίες του παρόχου, μέσω της πύλης Gateway, μπορεί να γίνει μόνο από ιστοτόπους με κατάληξη «.gr» για την Ελλάδα.

Ο πάροχος οφείλει για φιλοξενεί την πύλη Gateway εντός ΕΕ ή ΕΟΧ. To data center που φιλοξενεί την πύλη πρέπει να πληροί τις προδιαγραφές που περιγράφονται στο κεφάλαιο Ασφάλεια Υποδομών IT.

Τέλος, ο Κάτοχος της Άδειας εξασφαλίζει ότι, τα δεδομένα πύλης είναι σε τέτοια μορφή, ώστε να μπορούν να χρησιμοποιηθούν από μια διαδικασία ελέγχου της Αρχής. Συγκεκριμένα, θα πρέπει να παρέχεται στην Αρχή η δυνατότητα της παρακολούθησης και της εγγραφής για πεπερασμένο χρονικό διάστημα, όλων των συναλλαγών (κίνηση διαδικτύου) που λαμβάνουν χώρα, σε πραγματικό χρόνο, από τους παίκτες και διοχετεύονται, μέσω της πύλης, στην κεντρική πλατφόρμα του παρόχου.

25.6 Διαχείριση της πρόσβασης στα δεδομένα και λοιπές υποχρεώσεις Κατόχου Άδειας

25.6.1 Μέθοδοι και διαχείριση της πρόσβασης στα δεδομένα

Πρόσβαση στα δεδομένα που αποθηκεύονται στον κύριο αποθηκευτικό χώρο έχει μόνο η Αρχή.

Η πρόσβαση στα δεδομένα από την Αρχή γίνεται μέσω μιας σύνδεσης FTPS (FTP-SSL, implicit) στην πόρτα 990. Για την πρόσβαση απαιτείται η χρήση ψηφιακού πιστοποιητικού X.509 που εκδίδεται από την Αρχή.

Η πρόσβαση στον εναλλακτικό χώρο αποθήκευσης πραγματοποιείται με τον ίδιο ακριβώς τρόπο.

Η πρόσβαση στα δεδομένα που περιλαμβάνονται τόσο στο Safe, όσο και στον εναλλακτικό χώρο αποθήκευσης γίνεται μόνο από προκαθορισμένες IP διευθύνσεις που ορίζονται από την Αρχή και κοινοποιούνται στον Κάτοχο της Άδειας.

Η μεταφορά δεδομένων μεταξύ του Safe και της Αρχής πρέπει να πραγματοποιείται μέσω του Διαδικτύου, με ελάχιστη ταχύτητα 8 Mbit / δευτερόλεπτο. Ο Κάτοχος της Άδειας πρέπει να διασφαλίζει ότι η σύνδεση είναι κατάλληλη για την ομαλή μεταφορά των δεδομένων.

Ο μέσος χρόνος που απαιτείται προκειμένου η Αρχή να αποκτήσει πρόσβαση στα δεδομένα (login time) δε μπορεί να υπερβαίνει τα 15 δευτερόλεπτα.

25.6.2 Διαθεσιμότητα της πρόσβασης στα δεδομένα

Όπως αναφέρθηκε και παραπάνω, η διαθεσιμότητα τόσο της διάταξης ασφαλούς αποθήκευσης, όσο των λοιπών υποσυστημάτων του ενδιάμεσου συστήματος ελέγχου, αλλά και της πύλης Gateway, πρέπει να είναι τουλάχιστον 99,95%. Στην περίπτωση της πρόσβασης στα δεδομένα, η Αρχή θα πρέπει να διαθέτει διαβαθμισμένη πρόσβαση και στον εναλλακτικό χώρο αποθήκευσης, σε περίπτωση μη διαθεσιμότητας του κύριου αποθηκευτικού χώρου.

25.6.3 Συμπληρωματικοί τρόποι πρόσβασης στα δεδομένα

Στην Αρχή, εκτός της πρόσβασης στα δεδομένα, μέσω του Safe, παρέχονται και οι παρακάτω δυνατότητες απομακρυσμένης πρόσβασης:

  • Μέσω της πύλης Gateway: Στην Αρχή παρέχεται η δυνατότητα της παρακολούθησης και της εγγραφής, για πεπερασμένο χρονικό διάστημα, όλων των συναλλαγών (κίνηση διαδικτύου) που λαμβάνουν χώρα, σε πραγματικό χρόνο, από τους παίκτες και κατευθύνονται μέσω της πύλης στην κεντρική πλατφόρμα του παρόχου.
  • Μέσω της Κεντρικής πλατφόρμας του Παρόχου: Κατόπιν ειδοποίησης, ο Κάτοχος της Άδειας οφείλει να παρέχει πρόσβαση στην Aρχή, στο σύστημα βάσεων δεδομένων της κεντρικής πλατφόρμας του παρόχου, μέσω μιας read-only σύνδεσης απομακρυσμένης επιφάνειας εργασίας (μέσω εκπροσώπου του παρόχου). Στο πλαίσιο της εν λόγω συνεδρίας, ενδέχεται να ζητηθεί από τον εκπρόσωπο του παρόχου η εμφάνιση, η αποθήκευση και η αποστολή στην Αρχή συγκεκριμένων συνόλων δεδομένων που ορίζει η Αρχή.

25.6.4 Φυσική πρόσβαση στο ενδιάμεσο σύστημα ελέγχου και στην πύλη Gateway

Κατόπιν αιτήματος της Αρχής θα πρέπει να παρέχεται η δυνατότητα φυσικής πρόσβασης στους χώρους που φιλοξενούνται τα υποσυστήματα του ενδιάμεσου συστήματος ελέγχου και η πύλη (Gateway). Στο πλαίσιο αυτό, με στόχο τη διευκόλυνση του ελεγκτικού και εποπτικού έργου της Αρχής, θα πρέπει τα δεδομένα τόσο στο Safe, όσο και στην πύλη (Gateway), να είναι επιτόπου προσπελάσιμα από εξουσιοδοτημένα στελέχη της Αρχής.

Ταυτόχρονα, η Αρχή θα πρέπει να έχει τη δυνατότητα αντιγραφής των δεδομένων του Safe σε αποσπώμενο μέσο αποθήκευσης.

25.6.5 Συντήρηση της διάταξης ασφαλούς αποθήκευσης (Safe) από τον Κάτοχο Άδειας

Η συντήρηση και ο τεχνικός έλεγχος των υποδομών του ενδιάμεσου συστήματος ελέγχου και της πύλης Gateway είναι αποκλειστική αρμοδιότητα του Κατόχου της Άδειας. Ο Κάτοχος της Άδειας οφείλει να τηρεί τις διαδικασίες που περιγράφονται αναλυτικά στην ΔΙΑΧΕΙΡΙΣΗ ΑΛΛΑΓΩΝ ΣΤΑ ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΕΞΑΓΩΓΗΣ ΤΥΧΕΡΩΝ ΠΑΙΓΝΙΩΝ ΤΩΝ ΚΑΤΟΧΩΝ ΑΔΕΙΑΣ. Επιπρόσθετα, για τη διάταξη ασφαλούς αποθήκευσης (Safe), πρέπει να τηρούνται και οι προδιαγραφές που ορίζονται στον πίνακα που ακολουθεί.

 

Πίνακας 1. Προδιαγραφές για τη συντήρηση του Safe από τον Κάτοχο Άδειας

Τύπος παρέμβασηςΧρονικό παράθυρο παρέμβασηςΜέγιστη διάρκεια παρέμβασης
Τυπικές αλλαγές, patches, updates κ.τ.λ.·         Το ανώτερο μια φορά κάθε εργάσιμη ημέρα (Δευτέρα έως Παρασκευή) 18:00 – 06:00.

·         Το ανώτερο 2 φορές ανά εβδομάδα, το χρονικό διάστημα Σάββατο 06:00 μέχρι Δευτέρα 06:00.

90 λεπτά
Χρονοβόρες ενημερώσειςΤο πολύ 4 φορές ανά μήνα, το χρονικό διάστημα Σάββατο 06:00 μέχρι Δευτέρα 06:00.10 ώρες
Αλλαγές στην αρχιτεκτονική ή στις υπηρεσίεςΤο πολύ 4 φορές ανά έτος, το χρονικό διάστημα Σάββατο 06:00 μέχρι Δευτέρα 06:00.24 ώρες
Έκτακτα περιστατικάΚατόπιν συνεννόησηςΚατόπιν συνεννόησης

 

 

25.6.6 Έκτακτα περιστατικά της διάταξης ασφαλούς αποθήκευσης (Safe)

Σε περίπτωση που συμβεί κάποιο έκτακτο περιστατικό, το οποίο επηρεάζει την απρόσκοπτη λειτουργία του Safe, πρέπει αυτό να κοινοποιείται στην Αρχή και να επιλύεται, σύμφωνα με τα οριζόμενα στον πίνακα που ακολουθεί.Όλα τα έκτακτα περιστατικά πρέπει να επιλύονται σε ποσοστό τουλάχιστον 95%, το οποίο μετριέται σε τριμηνιαία βάση.Η υποβολή των εκτάκτων περιστατικών πραγματοποιείται σύμφωνα τις διαδικασίες που περιγράφονται αναλυτικά στην ΔΙΑΧΕΙΡΙΣΗ ΑΛΛΑΓΩΝ ΣΤΑ ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΕΞΑΓΩΓΗΣ ΤΥΧΕΡΩΝ ΠΑΙΓΝΙΩΝ ΤΩΝ ΚΑΤΟΧΩΝ ΑΔΕΙΑΣ.

 

Πίνακας 2. Προδιαγραφές για αντιμετώπιση έκτακτων περιστατικών

Τύπος περιστατικούΣυνέχιση υπηρεσίαςΜέγιστη διάρκεια παρέμβασης
ΚρίσιμοΔιακοπή υπηρεσίας6 ώρες
ΜεσαίοΣυνέχιση υπηρεσίας μέσω υπάρχουσας εναλλακτικής διαδικασίας.2 εργάσιμες ημέρες
ΆγνωστοΣυνέχιση υπηρεσίας μέσω εναλλακτικής διαδικασίας, η οποία πρέπει να υλοποιηθεί.4 εργάσιμες ημέρες

25.6.7 Υπεύθυνοι επικοινωνίας Κατόχου Άδειας για τεχνικά θέματα

Εκτός από τις απαιτήσεις σχετικά με τους διαφορετικούς ρόλους και τα άτομα, που η νομοθεσία ορίζει ως προϋπόθεση για την έκδοση άδειας, ο Κάτοχος Άδειας πρέπει να καθορίσει τουλάχιστον τους ακόλουθους τεχνικούς ρόλους:

  • Υπεύθυνος για τη λειτουργία και την ασφάλεια του ενδιάμεσου συστήματος και λοιπών υποσυστημάτων.
  • Υπεύθυνος για τις τεχνικές εργασίες και τη συντήρηση της υποδομής.

25.7 Μοντέλα δεδομένων

25.7.1 Μοντέλα δεδομένων

Τα μοντέλα δεδομένων είναι διαθέσιμα στην ιστοσελίδα της Ε.Ε.Ε.Π. (https://www.gamingcommission.gov.gr).

25.7.2 Μοντέλο δεδομένων για το αρχείο ελέγχου xml

25.7.2.1 Ονοματολογία xml αρχείου

Το αρχείο ελέγχου xml πρέπει έχει την ονομασία «manifest.xml».

25.7.2.2 Σχηματική περιγραφή μοντέλου δεδομένων xsd

Εικόνα 4. Μοντέλο δεδομένων για το αρχείο ελέγχου xml

 

25.7.2.3 Αναλυτική περιγραφή μοντέλου δεδομένων xsd

Το αρχείο ελέγχου είναι ένα συμπληρωματικό αρχείο xml, το οποίο συνοδεύει κάθε πακέτο δεδομένων που αποθηκεύεται στο Safe. Φέρει όλη την απαραίτητη πληροφορία ελέγχου (μεταδεδομένα) του εκάστοτε αρχείου δεδομένων xml που περιέχεται σε κάθε πακέτο δεδομένων. Οι βασικότερες πληροφορίες που περιέχονται στο αρχείο ελέγχου αφορούν τα αναγνωριστικά διασύνδεσης των διαδοχικών πακέτων δεδομένων (chaining hash values), τις παραμέτρους που χρησιμοποιούνται για τη συμπίεση και την κρυπτογράφηση των πακέτων δεδομένων και την ψηφιακή υπογραφή κάθε πακέτου δεδομένων που αποθηκεύεται στο Safe.

Ειδικότερα, η πληροφορία που περιέχεται στο αρχείο ελέγχου είναι η εξής:

  • Αναγνωριστικό, μονοσήμαντο όνομα του Κατόχου της Άδειας (hgc:licenseholderId).
  • Ημερομηνία και ώρα δημιουργίας του αρχείου ελέγχου (hgc:generationDate).
  • Αύξων αριθμός του αρχείου ελέγχου (hgc:manifestSequenceNumber).
  • Μεταδεδομένα του αρχείου δεδομένων xml του πακέτου δεδομένων (hgc:metadata):
    • Αριθμός εγγραφών που περιέχονται στο αρχείο xml (hgc:numberOfRecords).
    • Ημερομηνία και ώρα της πρώτης εγγραφής στο αρχείο xml (hgc:datetimeFirstRecord).
    • Ημερομηνία και ώρα της τελευταίας εγγραφής στο αρχείο xml (hgc:datetimeLastRecord).
    • Μέγεθος του μη συμπιεσμένου αρχείου δεδομένων xml σε bytes (hgc:sizeUncompressed).
    • Μέγεθος του συμπιεσμένου αρχείου δεδομένων xml σε bytes (hgc:sizeCompressed).
  • To δυναμικά παραγόμενο συμμετρικό κλειδί (AES256), με το οποίο είναι ασυμμετρικά κρυπτογραφημένο το αρχείο δεδομένων, κάνοντας χρήση του δημόσιου κλειδιού της Αρχής (πιστοποιητικό X.509), σύμφωνα με το πρότυπο W3C XML Encryption (https://www.w3.org/TR/xmlenc-core/) (xenc:EncryptedKey).
  • Αναφορά στα κρυπτογραφημένα δεδομένα σύμφωνα με το πρότυπο W3C XML Encryption (xenc:EncryptedData).
  • Οι πληροφορίες σύνδεσης των διαδοχικών πακέτων δεδομένων (chaining) (dsig:Manifest).
  • Η ψηφιακή υπογραφή του πακέτου δεδομένων, συμπεριλαμβανομένης και της χρονοσήμανσης του, σύμφωνα με το πρότυπο XAdES (dsig:Signature).

Παρακάτω παρουσιάζονται λεπτομέρειες για τη μεθοδολογία σύνταξης του αρχείου ελέγχου xml.

/hgc:licenseholderId

Αναγνωριστικό, μονοσήμαντο όνομα του Κατόχου της Άδειας.

/hgc:generationDate

Ημερομηνία και ώρα δημιουργίας του αρχείου ελέγχου.

/hgc:manifestSequenceNumber

Αύξων αριθμός του αρχείου ελέγχου (Ακέραιος αριθμός Ν >=1). Ταυτίζεται με τον αύξοντα αριθμό πακέτου δεδομένων.

/hgc:metadata

Μεταδεδομένα του αρχείου δεδομένων xml του πακέτου δεδομένων (συγκεντρωτικά δεδομένα).

/hgc:metadata/hgc:numberOfRecords

Αριθμός εγγραφών που περιέχονται στο αρχείο xml.

/hgc:metadata/hgc:dateFirstRecord

Ημερομηνία και ώρα της πρώτης εγγραφής στο αρχείο xml.

/hgc:metadata/hgc:dateLastRecord

Ημερομηνία και ώρα της τελευταίας εγγραφής στο αρχείο xml.

/hgc:metadata/hgc:sizeUncompressed

Μέγεθος του μη συμπιεσμένου αρχείου δεδομένων xml σε bytes

/hgc:metadata/hgc:sizeCompressed

Μέγεθος του συμπιεσμένου αρχείου δεδομένων xml σε bytes.

/xenc:EncryptedKey

Το στοιχείο <xenc:EncryptedKey> περιέχει το δυναμικά παραγόμενο συμμετρικό κλειδί (AES256), με το οποίο είναι ασυμμετρικά κρυπτογραφημένο το αρχείο δεδομένων, κάνοντας χρήση του δημόσιου κλειδιού της Αρχής (πιστοποιητικό X.509), σύμφωνα με το πρότυπο W3C XML Encryption. Το στοιχείο επίσης περιέχει ένα αναγνωριστικό όνομα για την αναγνώριση του συμμετρικού κλειδιού <xenc: CarriedKeyName>.

Σύμφωνα με το πρότυπο W3C XML Encryption, η δομή του συγκεκριμένου στοιχείου θα πρέπει να είναι ως εξής:

<xenc:EncryptedKey Id=»NameOfRegulator» xmlns=»http://www.w3.org/2001/04/xmlenc#»>

< xenc:EncryptionMethod Algorithm=»http://www.w3.org/2001/04/xmlenc#rsa-1_5″/>

<dsig:KeyInfo xmlns:ds=»http://www.w3.org/2000/09/xmldsig#»>

<dsig:X509Data>

<dsig:X509SubjectName>CN=Regulator, OU=Authority</dsig:X509SubjectName>

</dsig:X509Data>

</dsig:KeyInfo>

<xenc:CipherData>

<CipherValue>xyzi…rO+abc</CipherValue>

</xenc:CipherData>

<xenc:CarriedKeyName>K20</xenc:CarriedKeyName>

</xenc:EncryptedKey>

Στην περίπτωση που υπάρχουν περισσότερα πιστοποιητικά κρυπτογράφησης X.509 της/των ελεγκτικής(-ών) αρχής(-ών), τότε πρέπει να δημιουργηθούν περισσότερα στοιχεία <xenc:EncryptedKey>, τα οποία θα περιέχουν το ίδιο συμμετρικό κλειδί και όνομα, αλλά θα δείχνουν στο εκάστοτε πιστοποιητικό κρυπτογράφησης X.509 της ελεγκτικής αρχής (ds:X509SubjectName). Σαν αναγνωριστικό Id του στοιχείου <xenc:EncryptedKey>, θα δίνεται ένα αναγνωριστικό όνομα για την εποπτεύουσα αρχή για την οποία δημιουργείται το στοιχείο αυτό. Το αναγνωριστικό όνομα θα κοινοποιηθεί στον Κάτοχο της Άδειας από την Αρχή.

Σαν όνομα του για την αναγνώριση του συμμετρικού κλειδιού <xenc: CarriedKeyName> χρησιμοποιούμε τον αύξοντα αριθμό του αρχείου ελέγχου (π.χ. 20), με την προσθήκη του προθέματος K (Key).

/xenc:EncryptedData

Αυτό το στοιχείο αντιπροσωπεύει την αναφορά στα κρυπτογραφημένα δεδομένα, σύμφωνα με το πρότυπο κρυπτογράφησης XML Encryption. Περιέχει τον αλγόριθμο κρυπτογράφησης (AES256), καθώς και την εσωτερική αναφορά στο συμμετρικό κλειδί, μέσω του ονόματός του <xenc: CarriedKeyName>.

Η αναφορά στα κρυπτογραφημένα δεδομένα γίνεται μέσω ενός URI, το οποίο σχηματίζεται ως ακολούθως:

  • Τη διαδρομή URL του αρχείου zip. Η διαδρομή αντιστοιχεί στη δενδρική δομή φακέλων του Safe. Παράδειγμα:

<licenseholder>_<licenseid>_<seqno>_<YYYYMMDD>_<hhmmss>.zip

  • Τη διαδρομή του συμπιεσμένου και κρυπτογραφημένου αρχείου δεδομένων data.bin μέσα στο αρχείο zip. Παράδειγμα:

/data.bin

Στο τελικό στοιχείο <xenc:EncryptedData> προστίθεται ένα αναγνωριστικό Id, βάσει του οποίου θα γίνει η σύνδεση των διαδοχικών πακέτων (chaining), όπως παρουσιάζεται παρακάτω στην περιγραφή του στοιχείου < dsig:manifest >.

Συνεπώς, το στοιχείο <xenc:EncryptedData> θα έχει την παρακάτω μορφή:

<xenc:EncryptedData xmlns:xenc=»http://www.w3.org/2001/04/xmlenc#» Id=»D20″>

<xenc:EncryptionMethod Algorithm=»http://www.w3.org/2001/04/xmlenc#aes256-cbc»/>

<dsig:KeyInfo xmlns:ds=»http://www.w3.org/2000/09/xmldsig#»>

<dsig:KeyName>K20</dsig:KeyName>

</dsig:KeyInfo>

<xenc:CipherData>

<xenc:CipherReference

URI=»/<licenseholder>/<licenseid>/2019/01/01/<licenseholder>_<licenseid>_20_20190101_155502.zip/data.bin»/>

</xenc:CipherData>

</xenc:EncryptedData>

Στο παραπάνω παράδειγμα, το αναγνωριστικό του στοιχείου <xenc:EncryptedData> (Id=»D20″), προκύπτει από τον αύξοντα αριθμό του πακέτου (20), με την προσθήκη του προθέματος D (Data), επειδή γίνεται αναφορά στο πακέτο δεδομένων.

Στην περίπτωση που έπρεπε να γίνει κάποια αναφορά στο αρχείο ελέγχου (manifest), χρησιμοποιούμε τον αύξοντα αριθμό του αρχείου ελέγχου (20), με την προσθήκη του προθέματος C (Control).

/dsig:manifest

Για τη σύνδεση των διαδοχικών πακέτων (batches) μεταξύ τους χρησιμοποιείται το στοιχείο <dsig:Manifest>. Το στοιχείο αυτό προέρχεται από το πρότυπο XadES (XMLDSIG). Περιέχει δύο αναφορές στα δεδομένα (τρέχοντος και προηγούμενου πακέτου) , συμπεριλαμβανομένων των αντίστοιχων hash τιμών τους.

Η δομή του στοιχείου αυτού συνοψίζεται ως εξής:

  • Περιέχει αναφορά στο αντίστοιχο <dsig:Manifest> στοιχείο του αμέσως προηγούμενου πακέτου zip που δημιουργήθηκε, συμπεριλαμβανομένης και της hash τιμής του αρχείου δεδομένων xml που υπολογίστηκε βάσει του προηγούμενου κανονικοποιημένου αρχείου δεδομένων xml (προδιαγραφή Exclusive XML Canonicalization [XML-C14N]).

Η αναφορά στο προηγούμενο πακέτο δεδομένων γίνεται μέσω ενός URI, το οποίο σχηματίζεται ως ακολούθως:

  • Τη διαδρομή URL του προηγούμενου αρχείου zip. Η διαδρομή αντιστοιχεί στη δενδρική δομή φακέλων του Safe, όπως ορίζεται στις ενότητες 5.4 και 5.11. Παράδειγμα:

<licenseholder>_<licenseid>_<seqno>_<YYYYMMDD>_<hhmmss>.zip

  • Τη διαδρομή του αρχείου ελέγχου manifest xml μέσα στο προηγούμενο αρχείο zip. Παράδειγμα:

/manifest.xml

  • Την αναφορά στο αναγνωριστικό Id του στοιχείου <dsig:Manifest> του προηγούμενου πακέτου zip (<dsig:Manifest Id=”PreviousID”>). Παράδειγμα:

#<Id>

  • Περιέχει αναφορά στο στοιχείο <xenc:EncryptedData> του τρέχοντος αρχείου ελέγχου, συμπεριλαμβανομένης και της hash τιμής του αρχείου δεδομένων xml που υπολογίστηκε βάσει του τρέχοντος κανονικοποιημένου αρχείου δεδομένων xml (προδιαγραφή Exclusive XML Canonicalization [XML-C14N]). Η τιμή hash υπολογίζεται στο μη κρυπτογραφημένο και μη συμπιεσμένο αρχείο δεδομένων xml.

Στη συνέχεια πρέπει να αναφέρονται οι κανόνες μετασχηματισμού (αποκρυπτογράφηση, αποσυμπίεση) που πρέπει να εφαρμοστούν προκειμένου να γίνει επαλήθευση της τιμής hash ενός πακέτου δεδομένων.

Συνεπώς, το στοιχείο <dsig:Manifest> θα έχει την παρακάτω μορφή:

<dsig:Manifest Id=»C20″>

<dsig:ReferenceURI=»/<licenseholder>/<licenseid>/2019/01/01/<licenseholder>_<licenseid>_19_20190101_145500/manifest.xml#C19″>

<dsig:Transforms>

<dsig:Transform Algorithm=»http://www.w3.org/2001/10/xml-exc-c14n#»/>

</dsig:Transforms>

<dsig:DigestMethod Algorithm=»http://www.w3.org/2001/04/xmlenc#sha256″/>

<dsig:DigestValue>PreviousHashValue</dsig:DigestValue>

</dsig:Reference>

 

<dsig:Reference URI=»#D20″>

<dsig:Transforms>

<dsig:Transform Algorithm=»Decryption algorithm»/>

<dsig:Transform Algorithm=»Decompress algorithm»/>

</dsig:Transforms>

<dsig:DigestMethod Algorithm=»http://www.w3.org/2001/04/xmlenc#sha256″/>

<dsig:DigestValue>CurrectHashValue</dsig:DigestValue>

</dsig:Reference>

</dsig:Manifest>

/dsig:Signature

Πρόκειται για το στοιχείο που περιλαμβάνει την ψηφιακή υπογραφή του πακέτου δεδομένων. Η ψηφιακή υπογραφή προστίθεται ως enveloped signature σύμφωνα με το πρότυπο XAdES, συμπεριλαμβανομένης και της χρονοσήμανσης (πρότυπο XΑdES-T).

  • 4 Φεβρουαρίου 2019, 12:05 | The Remote Gambling Association (RGA)
    Το βλέπω Θετικά/Αρνητικά:  

    25.4.2 Location of the SAFE: It would be highly preferable to allow operators to keep the SAFE in any location within the EU/EEA.

  • 4 Φεβρουαρίου 2019, 11:19 | Intralot
    Το βλέπω Θετικά/Αρνητικά:  

    25.4.8 Αντίγραφα ασφαλείας.
    Προτείνεται ο εναλλακτικός χώρος αποθήκευσης να βρίσκεται σε απόσταση τουλάχιστον 20 χιλιομέτρων από την κύρια διάταξη ασφαλούς αποθήκευσης.

  • 1 Φεβρουαρίου 2019, 20:09 | bet365
    Το βλέπω Θετικά/Αρνητικά:  

    “Chapter 7 Gaming intermediate control system requirements
    Introduction”
    “Η συσκευή ασφαλούς αποθήκευσης (Safe) πρέπει να πιστοποιείται από διεθνή οργανισμό”

    Θα υπάρχει κατάλογος εγκεκριμένων «διεθνών οργανισμών» (πρέπει να είναι ανεξάρτητα εργαστήρια δοκιμών) που επιτρέπεται να πιστοποιούν την ασφάλεια;

    “Άρθρο 25 Γενική Αρχιτεκτονική
    25.3.1.1 Batching – Data batches

    “Θα υπάρχει μόνο ένα αρχείο xml σε κάθε παρτίδα, για κάθε μοντέλο δεδομένων.”

    Αντί να διανέμονται οι μεμονωμένες εγγραφές XML σε μία δέσμη XML, συνιστούμε κάθε εγγραφή να είναι ένα ενιαίο αρχείο XML και η παρτίδα να είναι ένα αρχείο zip των συγκεκριμένων αρχείων εγγραφής.
    Από την εμπειρία μας, αυτό καθιστά την υλοποίηση ευκολότερη και φθηνότερη για τους χειριστές. Καθώς τα μεμονωμένα αρχεία είναι μικρότερα και στοχεύουν σε ένα συγκεκριμένο συμβάν, καθιστά επίσης πολύ πιο εύκολο να φορτωθούν δεδομένα για την Αρχή

    “25.3.1.4 Συμπίεση και Κρυπτογράφηση δεδομένων”
    “2..Στη συνέχεια, το παραγόμενο κλειδί AES256 κρυπτογραφείται ασυμμετρικά με τα δημόσια κλειδιά της Αρχής (πιστοποιητικό X.509), σύμφωνα με τη διαδικασία RSA2048 (2048 -bit RSA keys). “


    Αυτό απαιτεί από την Αρχή να εφαρμόσει το δικό της εργαλείο για να αποκρυπτογραφήσει και να φορτώσει τα δεδομένα.

    25.3.2 Διασύνδεση του υποσυστήματος data sealing με το Safe
    “Η διασύνδεση του υποσυστήματος data sealing με το Safe γίνεται μέσω μιας ασφαλούς σύνδεσης εικονικού ιδιωτικού δικτύου (VPN), από άκρο σε άκρο. “

    Αυτό πρέπει να δηλώνει ότι η σύνδεση μεταξύ του υποσυστήματος σφράγισης δεδομένων και του Safe είναι ασφαλής (κρυπτογραφημένη σύνδεση), αλλά δεν πρέπει να επιβάλλει συγκεκριμένη τεχνολογία για την επίτευξη της απαίτησης ασφάλειας. Για παράδειγμα, η απαίτηση μπορεί να ικανοποιηθεί με σύνδεση HTTPS. δεν χρειάζεται να είναι ένα VPN.

    25.4.1 Τεχνικές προδιαγραφές διάταξης ασφαλούς αποθήκευσης δεδομένων

    “5. Ο Κάτοχος Άδειας πρέπει να εξασφαλίσει ότι η Αρχή θα έχει ασφαλή πρόσβαση τόσο στη διάταξη ασφαλούς αποθήκευσης των δεδομένων (Safe), όσο και στον εναλλακτικό χώρο αποθήκευσης, σύμφωνα με τα οριζόμενα στην σχετική ενότητα. “


    Προκειμένου να ικανοποιηθεί η πρόσβαση, απαιτείται προηγούμενη κοινοποίηση.

    “10.Το Safe πρέπει να είναι διαθέσιμο 24/7, 365 ημέρες το χρόνο, με εγγυημένη διαθεσιμότητα τουλάχιστον 99,95%. “

    Ποια είναι η περίοδος κατά την οποία υπολογίζεται η διαθεσιμότητα (μηνιαία, τριμηνιαία, ετήσια);

    “12. Ο Κάτοχος της Άδειας πρέπει να εξασφαλίσει πρόσβαση στο Safe για την Αρχή, ώστε να είναι δυνατή η ακόλουθη σύνδεση: Η Αρχή πρέπει να έχει τη δυνατότητα πρόσβασης στο Safe μέσω μιας FTPS (FTP over SSL) σύνδεσης. Αναλυτικά οι προδιαγραφές της πρόσβασης της Αρχής στα δεδομένα περιγράφονται στη σχετική ενότητα. 
”

    Το FTPS είναι δύσκολο να ρυθμιστεί τόσο για τους πελάτες όσο και για τους διακομιστές. Σας συνιστούμε να αλλάξετε την απαίτηση για πρόσβαση στο SAFE μέσω HTTPS αντί για FTPS. Η ασφάλεια είναι η ίδια (και τα δύο πρωτόκολλα λειτουργούν μέσω SSL) αλλά το HTTPS είναι πιο εύκολο να υλοποιηθεί για τον χειριστή και την Αρχή και τα ζητήματα σύνδεσης είναι πολύ πιο εύκολο να λυθούν.

    25.4.7 Διατήρηση των δεδομένων

    Γιατί πρέπει να αρχειοθετούνται τα δεδομένα εκτός σύνδεσης; Μπορεί να θέλουμε να το διατηρήσουμε στο διαδίκτυο. Αυτό σημαίνει ότι τα δεδομένα πρέπει να διατηρούνται επί 10 έτη και να διατίθενται στην Αρχή online για τα τελευταία 5 έτη και εντός 2 ημερών για τα παλαιότερα δεδομένα.

    25.4.8 Αντίγραφα ασφαλείας
    “Σε περίπτωση ενός σοβαρού περιστατικού καταστροφής του κύριου αποθηκευτικού χώρου, το χρονικό διάστημα επαναφοράς του σε πλήρη λειτουργία, με όλα τα δεδομένα, όπως ήταν στην προτέρα κατάστασή του, δε μπορεί να ξεπερνά τις πέντε (5) ημερολογιακές ημέρες. “

    Απαιτείται περαιτέρω διευκρίνιση – Σε περίπτωση «σοβαρού συμβάντος καταστροφής» δεν θεωρούμε ότι επαρκείς χρόνοι για την αποκατάσταση του κύριου χώρου αποθήκευσης είναι 5 ημέρες.

    25.4.10 Διόρθωση δεδομένων / Ακύρωση εγγραφής
    ¨Δημιουργείται μια νέα πλήρης εγγραφή, με το σύνολο των δεδομένων που υπάρχουν στην προς αντικατάσταση εγγραφή και με ειδική αναφορά στην αρχική καταγεγραμμένη εγγραφή (previous record id). 
”

    Η εργασία με την αντικατάσταση πλήρους αρχείου είναι πολύπλοκη για τους φορείς εκμετάλλευσης αλλά κυρίως για την Αρχή, διότι απαιτεί από την Αρχή να διατηρεί πλήρη λίστα αναφοράς των προηγούμενων αρχείων και των σχετικών δεδομένων για να γνωρίζει επακριβώς τα δεδομένα που θα αντικαταστήσουν.
    Συνιστούμε να αναφέρετε όσο το δυνατόν περισσότερο τη διόρθωση δεδομένων ως «deltas». Για παράδειγμα, εάν έχει αναφερθεί τιμή «20 €» και θα πρέπει στη συνέχεια να διορθωθεί σε «15 €», τότε ο φορέας εκμετάλλευσης θα αναφέρει μια διόρθωση «-5 €».

    25.4.11 Κατ’ απαίτηση αποστολή δεδομένων
    “
Η Αρχή μπορεί να ζητά από τον Κάτοχο της Άδειας συμπληρωματικά δεδομένα, εφόσον κρίνεται σκόπιμο. Σε περίπτωση που το μοντέλο των δεδομένων που ζητούνται από την Aρχή, δε συμπεριλαμβάνεται στη λίστα με τα διαθέσιμα μοντέλα δεδομένων, η Aρχή οφείλει να αποστέλλει στον Κάτοχο της Άδειας και το σχετικό μοντέλο δεδομένων. 


    […]
    Τα αρχεία που αποθηκεύονται στη διάταξη ασφαλούς αποθήκευσης θα πρέπει να φέρουν το χαρακτηριστικό αναγνωριστικό «_od_» στην ονομασία τους, στη συνέχεια του αναγνωριστικού , ώστε να διασφαλιστεί η αναγνώρισή τους ως «κατ’ απαίτηση δεδομένα». 
”

    Απαιτούνται περαιτέρω διευκρινίσεις – Τα κατ’ απαίτηση δεδομένα είναι πιθανώς μια εφάπαξ ή προσωρινή ανάγκη για περισσότερες πληροφορίες που απαιτούν γρήγορη ανάκαμψη. Δεδομένου ότι η εφαρμογή νέων μοντέλων δεδομένων στο Safe διαρκεί σημαντικό χρονικό διάστημα και μπορεί να απαιτεί μια άλλη πιστοποίηση από διεθνή οργανισμό, συνιστούμε να παρέχονται πληροφορίες στην Αρχή μέσω ενός καναλιού διαφορετικού από το Safe.

    25.5 Gateway
    “…Συγκεκριμένα, θα πρέπει να παρέχεται στην Αρχή η δυνατότητα της παρακολούθησης και της εγγραφής για πεπερασμένο χρονικό διάστημα, όλων των συναλλαγών (κίνηση διαδικτύου) που λαμβάνουν χώρα, σε πραγματικό χρόνο, από τους παίκτες και διοχετεύονται, μέσω της πύλης, στην κεντρική πλατφόρμα του παρόχου.”

    Απαιτούνται περαιτέρω διευκρινίσεις – Αυτό απαιτεί να εισαχθούν σημαντικές ανησυχίες για την προστασία των δεδομένων και PCI και θα μπορούσαν ενδεχομένως να οδηγήσουν σε μη συμμόρφωση και στις δύο πλευρές (Operator & Regualtor).

    25.6.1 Μέθοδοι και διαχείριση της πρόσβασης στα δεδομένα
    “Η μεταφορά δεδομένων μεταξύ του Safe και της Αρχής πρέπει να πραγματοποιείται μέσω του Διαδικτύου, με ελάχιστη ταχύτητα 8 Mbit / δευτερόλεπτο. Ο Κάτοχος της Άδειας πρέπει να διασφαλίζει ότι η σύνδεση είναι κατάλληλη για την ομαλή μεταφορά των δεδομένων. “

    Απαιτούνται περαιτέρω διευκρινίσεις – Δεν είμαστε σε θέση να ελέγξουμε τις ταχύτητες του διαδικτύου από τους τελικούς χρήστες.

    25.6.2 Διαθεσιμότητα της πρόσβασης στα δεδομένα
    “Όπως αναφέρθηκε και παραπάνω, η διαθεσιμότητα τόσο της διάταξης ασφαλούς αποθήκευσης, όσο των λοιπών υποσυστημάτων του ενδιάμεσου συστήματος ελέγχου, αλλά και της πύλης Gateway, πρέπει να είναι τουλάχιστον 99,95%. Στην περίπτωση της πρόσβασης στα δεδομένα, η Αρχή θα πρέπει να διαθέτει διαβαθμισμένη πρόσβαση και στον εναλλακτικό χώρο αποθήκευσης, σε περίπτωση μη διαθεσιμότητας του κύριου αποθηκευτικού χώρου. “

    Απαιτούνται περαιτέρω διευκρινίσεις – 99,95% σε σχέση με το χρονικό διάστημα; Επίσης, τι σημαίνει «διαβαθμισμένη πρόσβαση»;

    25.6.3 Συμπληρωματικοί τρόποι πρόσβασης στα δεδομένα

    Απαιτούνται περαιτέρω διευκρινίσεις – Θα πρέπει να κατανοήσουμε πώς θα επιτευχθεί αυτή η απαίτηση.

    25.6.5 Συντήρηση της διάταξης ασφαλούς αποθήκευσης (Safe) από τον Κάτοχο Άδειας 

    “Πίνακας 1”

    Απαιτούνται περαιτέρω διευκρινίσεις – Σημαίνει ότι δεν επιτρέπεται στον φορέα εκμετάλλευσης να διορθώσει έκτακτη ανάγκη πριν εγκριθεί από την Αρχή;

    25.6.6 Έκτακτα περιστατικά της διάταξης ασφαλούς αποθήκευσης (Safe)

    Απαιτούνται περαιτέρω διευκρινίσεις – πιστεύουμε ότι αυτός ο πίνακας αντιφάσκει με το ποσοστό διαθεσιμότητας στην απαίτηση 25.6.2 επίσης. Τι σημαίνει για να επιλυθεί έκτακτη ανάγκη σε ποσοστό 95%;

    25.7.2.3 Αναλυτική περιγραφή μοντέλου δεδομένων xsd

    “/xenc:EncryptedKey
    Σαν όνομα του για την αναγνώριση του συμμετρικού κλειδιού χρησιμοποιούμε τον αύξοντα αριθμό του αρχείου ελέγχου (π.χ. 20), με την προσθήκη του προθέματος K (Key). “

    Το μεταφερόμενο κλειδί δεν χρειάζεται ένα όνομα, υπάρχει μόνο ένα συμμετρικό κλειδί και περιέχεται στο αρχείο manifest.xml.
    Συνιστούμε στην Αρχή να χρησιμοποιεί το μοντέλο Schleswig Holstein για κρυπτογράφηση και υπογραφή χωρίς τροποποίηση, έχει χρησιμοποιηθεί με απόλυτη επιτυχία και με αποδείξεις όλα αυτά τα χρόνια.

    “/xenc:EncryptedData
    “Στο τελικό στοιχείο προστίθεται ένα αναγνωριστικό Id, βάσει του οποίου θα γίνει η σύνδεση των διαδοχικών πακέτων (chaining), όπως παρουσιάζεται παρακάτω στην περιγραφή του στοιχείου .
    ……….
    Στην περίπτωση που έπρεπε να γίνει κάποια αναφορά στο αρχείο ελέγχου (manifest), χρησιμοποιούμε τον αύξοντα αριθμό του αρχείου ελέγχου (20), με την προσθήκη του προθέματος C (Control). “
    Η ετικέτα URI είναι ήδη η απαιτούμενη αναφορά στα δεδομένα παρτίδας και τον αριθμό σειράς. Η αλληλεπικάλυψη του ίδιου στοιχείου στο ίδιο αρχείο XML δεν προσθέτει περαιτέρω αξία ή πληροφορίες. Συνιστούμε στην Αρχή να χρησιμοποιεί το υπάρχον και αποδεδειγμένο μοντέλο Schleswig Holstein για κρυπτογράφηση και υπογραφή χωρίς καμία τροποποίηση.

    Notes:
    Όλες οι εξωτερικές συνδέσεις στα συστήματά μας (ICS, THAM, PPSE, IAPR κ.λπ.) χρειάζονται περισσότερη σαφήνεια και κατανόηση των απαιτήσεων.

  • 1 Φεβρουαρίου 2019, 13:10 | GVC
    Το βλέπω Θετικά/Αρνητικά:  

    Θα θέλαμε να δηλώσουμε την προτίμησή μας να υπάρχει η δυνατότητα το Safe να βρίσκεται σε οποιαδήποτε τοποθεσία εντός της ΕΕ/ΕΟΧ, δεδομένου του κοινού Ευρωπαϊκού ρυθμιστικού πλαισίου

  • 1 Φεβρουαρίου 2019, 12:32 | ΟΠΑΠ Α.Ε.
    Το βλέπω Θετικά/Αρνητικά:  

    Άρθρο 25 Γενική Αρχιτεκτονική
    Απόψεις / Παρατηρήσεις – Προτάσεις:

    1. Δεν αναφέρονται οι στόχοι (goals and objectives) της ύπαρξης του Ενδιάμεσου Συστήματος Ελέγχου (ΕΣΕ). Προβλέπεται η δημιουργία ενός συστήματος χωρίς να είναι γνωστοί οι όροι και ο τρόπος χρήσης του από την Αρχή. Ως εκ τούτου η χρήση του ΕΣΕ κρίνεται απολύτως ασαφής. Το ίδιο ισχύει και για κάθε άλλο είδος πρόσβασης.

    2. Η Αρχή θα πρέπει να προσδιορίσει το είδος των δεδομένων που θα πρέπει να παρέχονται, καθώς αυτό θα καθορίσει το κόστος και την πολυπλοκότητα υλοποίησης του ΕΣΕ στο σύνολό του. Χωρίς τον εν λόγω προσδιορισμό, δεν είναι ευχερής η αξιολόγηση της εμπορικής βιωσιμότητας της απόκτησης και λειτουργίας Άδειας Διεξαγωγής Τυχερών Παιγνίων μέσω Διαδικτύου, αφής στιγμής δεν δύναται να αποσαφηνιστεί το ύψους του κόστος που θα πρέπει να δαπανηθεί προκειμένου τα συστήματα των παρόχων να τελούν σε πλήρη συμμόρφωση με το ρυθμιστικό πλαίσιο.

    Προτείνεται όπως στην εν λόγω ρύθμιση συμπεριληφθούν και τα δεδομένα των συναλλαγών του Παίκτη, δηλαδή δεδομένα που αφορούν στην εγγραφή του, τα στοιχήματά του, τις καταθέσεις και τις αποσύρσεις κεφαλαίων από τον Ηλεκτρονικό Λογαριασμό του. Η συμπερίληψη περαιτέρω δεδομένων όπως π.χ. αυτά που αφορούν στα στοιχηματικά γεγονότα (δηλ. αλλαγές σε τιμές αποδόσεων κλπ.), λαμβάνοντας υπόψη και την απαίτηση διατήρησης του συνόλου των δεδομένων για 10 χρόνια, θα καταστήσει το κόστος επένδυσης και υλοποίησης του ΕΣΕ ιδιαίτερα υψηλό, ενδεχομένως και απαγορευτικό.

    3. Η ύπαρξη και υλοποίηση της πύλης ελέγχου σε πραγματικό χρόνο (Gateway) μπορεί να επιφέρει σημαντικότατες αλλαγές στην υπάρχουσα αρχιτεκτονική των Παρόχων και δεν θα πρέπει να θεωρείται αυτονόητη. Επίσης, αφής στιγμής δεν προβλέπεται η ακριβής λειτουργία που θα επιτελεί η εν λόγω πύλη ελέγχου, εγείρονται ζητήματα που άπτονται της δυνατότητας υλοποίησής της.

    i. Πέραν της τεχνικής δυνατότητας υλοποίησης της πύλης ελέγχου σε πραγματικό χρόνο με την τρέχουσα τεχνολογία, η ύπαρξη ενός μοναδικού σημείου μέσω του οποίου θα κατευθύνεται όλη η διαδικτυακή κίνηση των παικτών, ενδέχεται να επηρεάσει τόσο την προσφορά υπηρεσιών προς τους παίκτες, όσο και το ιδιωτικό τους απόρρητο.

    ii. Η Αρχή ενδεχομένως να μπορεί να χρησιμοποιήσει στοιχεία επιπέδου δικτύου (network elements) με τα οποία θα μπορεί με τεχνικές δικτύου (π.χ. port mirroring) να παρακολουθήσει και να καταγράψει με δικά της μέσα τη διαδικτυακή (TCP/IP traffic) κίνηση προς τα κεντρικά συστήματα του Παρόχου. Κρίνεται σκόπιμο όπως η παρακολούθηση της διαδικτυακής κίνησης γίνεται από την Αρχή με δικά της μέσα αφής στιγμής δεν δύναται να αποτελέσει μέρος της τεχνικής υλοποίησης ενός Παρόχου.

    iii. Επίσης, θα πρέπει να είναι σαφές το πλαίσιο ενημέρωσης του τελικού πελάτη (καταναλωτή) για την παρακολούθηση της κίνησής του από τρίτους. Π.χ. θα πρέπει να τελεί πάντοτε σε γνώση του πελάτη (καταναλωτή) αν η Αρχή καταγράφει τις συναλλαγές του Θα υπάρχουν εξαιρέσεις, ήτοι περιπτώσεις που δεν θα χρειάζεται να ενημερώνεται ο πελάτης (καταναλωτής);

    4. Η Αρχή θα πρέπει να γνωστοποιήσει τις διαδικασίες με τις οποίες αποκτά τα δεδομένα από το Safe και να διασφαλίσει με κάθε δυνατό τρόπο τα δεδομένα του εκάστοτε Παρόχου. Π.χ. πώς διασφαλίζονται τα από-κρυπτογραφημένα δεδομένα κατά την επεξεργασία τους από τυχόν διαρροή προς τρίτους Παρόχους.

    5. Για να είναι εφικτή η πιστοποίηση των υλοποιήσεων των Παρόχων, θα πρέπει η Αρχή να δημιουργήσει και να παρέχει στους ενδιαφερόμενους πρόσβαση σε μια πρότυπη υλοποίηση του ΕΣΕ που η ίδια προτείνει (Reference implementation).

    6. Αναφορικά με την παράγραφο 25.2.1 όπου αναφέρεται ότι «Τα μοντέλα δεδομένων περιγράφονται από αντίστοιχα σχήματα XML (XML schemas). Πριν τα δεδομένα αποθηκευτούν και σφραγιστούν στη διάταξη ασφαλούς αποθήκευσης (“Safe”), πιστοποιούνται ως προς τη συμβατότητά τους με το μοντέλο δεδομένων, που ορίζει η Αρχή (validate XML against XSD). Τα αρχεία XSD θα είναι διαθέσιμα στους ενδιαφερόμενους μέσω του διαδικτυακού τόπου της Αρχής (https://www.gamingcommission.gov.gr).»:

    i. Η Αρχή θα πρέπει εγκαίρως να δημοσιεύσει και τα αντίστοιχα σχήματα (XML Schema), έτσι ώστε οι Πάροχοι να διασφαλίσουν ότι μπορούν ή όχι να παρέχουν την αντίστοιχη πληροφορία, καθώς και να αξιολογήσουν την εμπορική βιωσιμότητα της απόκτησης και λειτουργίας Άδειας Διεξαγωγής Τυχερών Παιγνίων μέσω Διαδικτύου όπως αναφέρεται στο σχόλιο υπό 2 ανωτέρω.
    ii. Σε περιπτώσεις όπου ο Πάροχος διαπιστώνει και αποδεικνύει αδυναμία παροχής της πληροφορίας λόγω έλλειψής της από το επιχειρησιακό του μοντέλο, η Αρχή θα πρέπει να έχει σαφείς εναλλακτικές επιλογές για τον Πάροχο.
    iii. Η Αρχή θα πρέπει να μπορεί να δεσμευτεί για την σταθερότητα του σχήματος (XML Schema) στο οποίο απαιτεί οι Πάροχοι να είναι συμβατοί.
    iv. Κάθε αλλαγή στο σχήμα των δεδομένων θα πρέπει να μπορεί να προγραμματίζεται από κοινού με τους Παρόχους και εφόσον τα αντίστοιχα κόστη υλοποίησης δεν ξεπερνούν συγκεκριμένα κατώφλια που θα πρέπει να οριστούν.

    7. Αναφορικά με την παράγραφο 25.4.2 είναι σημαντικό να διευκρινιστεί ο λόγος για τον οποίο η Αρχή προτείνει η διάταξη ασφαλούς αποθήκευσης (Safe) να υλοποιηθεί και να φιλοξενείται από τον εκάστοτε Πάροχο. Προτείνεται η εξής αλλαγή:
    i. οι Πάροχοι να «κλειδώνουν» τα δεδομένα με το ιδιωτικό τους κλειδί,
    ii. τα δεδομένα να μεταφέρονται στο Safe το οποίο θα βρίσκεται υπό την πλήρη ευθύνη και έλεγχο της Αρχής.
    iii. Με αυτόν τον τρόπο διευκολύνονται οι Πάροχοι στην υλοποίηση και η Αρχή έχει άμεση πρόσβαση στα δεδομένα, διασφαλίζοντας έτσι και την εγκυρότητα του Safe.

    8. Αναφορικά με την παράγραφο 25.4.11 όπου απαιτείται η αποστολή συμπληρωματικών δεδομένων, σημειώνουμε ότι οποιαδήποτε μοντέλο δεδομένων ζητηθεί που δεν συμπεριλαμβάνεται στη λίστα με τα διαθέσιμα μοντέλα, δημιουργεί σημαντικές εργασίες και κόστη από την πλευρά του Παρόχου. Η απαίτηση θα πρέπει να καταργηθεί και να δημιουργηθεί μια διαδικασία, η οποία θα ενσωματώνει τυχόν νέες απαιτήσεις της Αρχής όπως αναφέρουμε σε σχόλιό μας που αναρτήθηκε στο άρθρο 25.2.1.

    9. Στο άρθρο 25.6.3 και όπου απαιτούνται συμπληρωματικοί τρόποι πρόσβασης σημειώνουμε ότι η Αρχή, στο πλαίσιο της πιθανής απομεμακρυσμένης πρόσβασης στις κεντρικές πλατφόρμες των παρόχων, θα πρέπει να μεριμνά για τη μη διατάραξη της ασφαλούς και καλής λειτουργίας των κεντρικών συστημάτων του Παρόχου. Η αλληλεπίδραση, έστω και στη μορφή της ανάγνωσης θα πρέπει να διασφαλίζει την ομαλή εμπορική λειτουργία του Παρόχου. Η όλη διαδικασία θα πρέπει να σχεδιάζεται και να συμφωνείται από κοινού με τον κάθε Πάροχο και την Αρχή ξεχωριστά.

    10. Στο άρθρο 25.4.8 απαιτείται ο εναλλακτικός χώρος αποθήκευσης να βρίσκεται σε απόσταση τουλάχιστον 30 χιλιομέτρων από την κύρια διάταξη ασφαλούς αποθήκευσης. Σύμφωνα με τα σχόλιά μας που έχον αναρτηθεί στα άρθρα 30 & 31 του υπό διαβούλευση σχεδίου Κανονισμού η εν λόγω απόσταση δεν θα πρέπει να καθορίζεται με σταθερή τιμή αλλά σύμφωνα με τις βέλτιστες διεθνείς πρακτικές. Προτείνουμε η εν λόγω απόσταση να καθορίζεται μετά από αξιολόγηση που θα βασίζεται στους γεωγραφικούς κινδύνους της φυσικής έδρας εγκατάστασης της κύριας διάταξης ασφαλούς αποθήκευσης.