02008D0616 — BG — 25.04.2024 — 001.001


Този текст служи само за информационни цели и няма правно действие. Институциите на Съюза не носят отговорност за неговото съдържание. Автентичните версии на съответните актове, включително техните преамбюли, са версиите, публикувани в Официален вестник на Европейския съюз и налични в EUR-Lex. Тези официални текстове са пряко достъпни чрез връзките, публикувани в настоящия документ

►B

РЕШЕНИЕ 2008/616/ПВР НА СЪВЕТА

от 23 юни 2008 година

за изпълнение на Решение 2008/615/ПВР относно засилването на трансграничното сътрудничество, по-специално в борбата срещу тероризма и трансграничната престъпност

(ОВ L 210, 6.8.2008 г., стp. 12)

Изменено с:

 

 

Официален вестник

  №

страница

дата

►M1

РЕГЛАМЕНТ (ЕС) 2024/982 НА ЕВРОПЕЙСКИЯ ПАРЛАМЕНТ И НА СЪВЕТА  от 13 март 2024 година

  L 982

1

5.4.2024




▼B

РЕШЕНИЕ 2008/616/ПВР НА СЪВЕТА

от 23 юни 2008 година

за изпълнение на Решение 2008/615/ПВР относно засилването на трансграничното сътрудничество, по-специално в борбата срещу тероризма и трансграничната престъпност



ГЛАВА I

ОБЩИ ПОЛОЖЕНИЯ

Член 1

Цел

Целта на настоящото решение е да установи необходимите административни и технически разпоредби за изпълнение на Решение 2008/615/ПВР, по-специално по отношение на автоматизирания обмен на ДНК данни, дактилоскопични данни и данни за регистрацията на превозни средства, установени в глава 2 от посоченото решение, както и други форми на сътрудничество, установени в глава 5 от посоченото решение.

Член 2

Определения

За целите на настоящото решение:

а) 

„търсене“ и „сравняване“ съгласно посоченото в членове 3, 4 и 9 от Решение 2008/615/ПВР означават процедури, чрез които се установява дали има съвпадение съответно между ДНК данни или дактилоскопични данни, които са били съобщени от една държава-членка, и ДНК данни или дактилоскопични данни, съхранявани в базите данни на една, няколко или всички държави-членки;

б) 

„автоматизирано търсене“ съгласно посоченото в член 12 от Решение 2008/615/ПВР означава процедура за онлайн-достъп за справка в базите данни на една, няколко или всички държави-членки;

в) 

„ДНК профил“ означава буква или числов код, който представлява набор от идентификационни характеристики на некодиращата част на анализирана проба човешка ДНК, т.е. определена молекулярна структура в различните части на ДНК (локуси);

г) 

„некодираща част от ДНК“ означава хромозомни сектори, които нямат генетичен израз, т.е. за тях не е известно да осигуряват функционални свойства на даден организъм;

д) 

„референтни ДНК данни“ означава ДНК профил и референтен номер;

е) 

„референтен ДНК профил“ означава ДНК профил на идентифицирано лице;

ж) 

„неидентифициран ДНК профил“ означава ДНК профил, получен от следи, събрани по време на разследване на престъпления и принадлежащи на лице, което все още не е идентифицирано;

з) 

„забележка“ означава маркиране на ДНК профил от държава-членка в нейната национална база данни, посочващо, че вече е имало съвпадение на този ДНК профил при търсене или сравняване от друга държава-членка;

и) 

„дактилоскопични данни“ означава образи на пръстови отпечатъци, образи на следи от пръстови отпечатъци, отпечатъци на длани, следи на отпечатъци от длани, както и модели на такива образи (кодирани признаци (minutiae), когато те се съхраняват и обработват чрез автоматизирана база данни;

й) 

„данни за регистрацията на превозни средства“ означава съвкупността от данни, посочени в глава 3 от приложението към настоящото решение;

к) 

„отделен случай“, както е посочено в член 3, параграф 1, второ изречение, член 9, параграф 1, второ изречение и член 12, параграф 1 от Решение 2008/615/ПВР, означава отделно следствено дело или прокурорска преписка. В случай че такова дело или преписка съдържа повече от един ДНК профил или повече от един елемент от дактилоскопични данни или данни за регистрацията на превозно средство, те могат да бъдат изпратени заедно като едно искане.

▼M1 —————

▼B

ГЛАВА 6

ПОЛИЦЕЙСКО СЪТРУДНИЧЕСТВО

Член 17

Съвместни патрули и други съвместни операции

1.  
В съответствие с глава 5 от Решение 2008/615/ПВР, и по-специално с декларациите, подадени съгласно член 17, параграф 4 и член 19, параграфи 2 и 4 от посоченото решение, всяка държава-членка посочва една или повече точки за контакт, за да даде възможност на другите държави-членки да се обръщат към компетентни органи, и всяка държава-членка може да посочи своите процедури за установяване на съвместни патрули и други съвместни операции, процедурите си относно инициативите на други държави-членки във връзка с тези операции, както и други практически аспекти и реда и другите оперативни условия по отношение на тези операции.
2.  
Генералният секретариат на Съвета съставя и поддържа актуализиран списък на точките за контакт и информира компетентните органи за всяка промяна в този списък.
3.  

Компетентните органи на всяка държава-членка могат да предприемат инициатива за осъществяване на съвместна операция. Преди началото на конкретна операция компетентните органи, посочени в параграф 2, се договарят писмено или устно за подробности, като:

а) 

компетентните органи на държавите-членки за операцията;

б) 

конкретната цел на операцията;

в) 

държавата-членка домакин, в която трябва да се проведе операцията;

г) 

географската област от държавата-членка домакин, където трябва да се проведе операцията;

д) 

периодът, който обхваща операцията;

е) 

конкретната помощ, която да бъде предоставена от командироващата(ите) държава(и)-членка(и) на държавата-членка домакин, включително служители и друг персонал, материални и финансови ресурси;

ж) 

служителите, участващи в операцията;

з) 

служителят отговарящ за операцията;

и) 

правомощията, които служителите и други длъжностни лица от командироващата(ите) държава(и)-членка(и) могат да упражняват в държавата-членка домакин по време на операцията;

й) 

конкретното въоръжение, боеприпаси и оборудване, които командированите служители могат да използват по време на операцията в съответствие с Решение 2008/615/ПВР;

к) 

логистичните условия по отношение на транспорта, настаняването и сигурността;

л) 

разпределението на разходите по съвместната операция, ако то се различава от предвиденото в член 34, първо изречение от Решение 2008/615/ПВР;

м) 

възможни други необходими елементи.

4.  
Декларациите, процедурите и определянията, предвидени в настоящия член, се възпроизвеждат в наръчника, посочен в член 18, параграф 2.

ГЛАВА 7

ЗАКЛЮЧИТЕЛНИ РАЗПОРЕДБИ

▼M1 —————

▼B

Член 19

Независими органи за защита на данните

В съответствие с член 18, параграф 2 от настоящото решение държавите-членки информират генералния секретариат на Съвета относно независимите органи за защита на данните или съдебните органи, посочени в член 30, параграф 5 от Решение 2008/615/ПВР.

▼M1 —————

▼B

Член 22

Връзка със споразумението за изпълнение на Договора от Прюм

За държавите-членки, обвързани от Договора от Прюм, съответните разпоредби на настоящото решение и приложението към него, след пълното им изпълнение, се прилагат вместо съответстващите им разпоредби, съдържащи се в споразумението за изпълнение на Договора от Прюм. Всички други разпоредби от споразумението за изпълнение остават приложими между договарящите страни по Договора от Прюм.

Член 23

Изпълнение

Държавите-членки вземат необходимите мерки, за да спазят разпоредбите на настоящото решение в сроковете, посочени в член 36, параграф 1 от Решение 2008/615/ПВР.

Член 24

Прилагане

Настоящото решение поражда действие двадесет дни след публикуването му в Официален вестник на Европейския съюз.




ПРИЛОЖЕНИЕ

СЪДЪРЖАНИЕ

ГЛАВА 1:

Обмен на ДНК данни

1.

Свързани с ДНК криминалистични въпроси, правила и алгоритми за сравняване

1.1.

Свойства на ДНК профилите

1.2.

Правила за сравняване

1.3.

Правила за съобщаване на резултатите

2.

Таблица на кодовите номера на държавите-членки

3.

Функционален анализ

3.1.

Наличност на системата

3.2.

Втори етап

4.

Документ за контрол на интерфейса при обмен на ДНК данни

4.1.

Въведение

4.2.

Дефиниране на XML-структурата

5.

Архитектура на приложението, сигурността и комуникациите

5.1.

Обзорен преглед

5.2.

Архитектура на горното ниво

5.3.

Стандарти за сигурност и защита на данните

5.4.

Протоколи и стандарти, които да се използват за механизма за криптиране sMIME и свързани пакети

5.5.

Архитектура на приложението

5.6.

Протоколи и стандарти, които да се използват за архитектурата на приложението

5.7.

Комуникационна среда

ГЛАВА 2:

Обмен на дактилоскопични данни (документ за контрол на интерфейса)

1.

Обзор на съдържанието на файловете

2.

Формат на записите

3.

Логически запис тип-1: заглавна част на файла

4.

Логически запис тип-2: описателен текст

5.

Логически запис тип-4: изображение с висока резолюция в сивата скала

6.

Логически запис тип-9: запис на признаци (minutiae)

7.

Запис тип-13 на изображение на следи с променлива резолюция

8.

Запис тип-15 на изображение на отпечатък от длан с променлива резолюция

9.

Допълнения към глава 2 (обмен на дактилоскопични данни)

9.1.

ASCII разделителни кодове

9.2.

Изчисляване на буквено-цифровия контролен символ

9.3.

Символни кодове

9.4.

Кратко описание на транзакция

9.5.

Дефиниции на запис тип-1

9.6.

Дефиниции на запис тип-2

9.7.

Кодове за компресия в сивата скала

9.8.

Спецификация на съобщенията

ГЛАВА 3:

Обмен на данни за регистрацията на превозни средства

1.

Общ набор от данни за автоматизирано търсене на данни за регистрацията на превозни средства

1.1.

Определения

1.2.

Търсене на превозно средство/собственик/ползвател

2.

Сигурност на данните

2.1.

Обзорен преглед

2.2.

Характеристики на сигурността, свързани с обмена на съобщения

2.3.

Характеристики на сигурността, несвързани с обмена на съобщения

3.

Технически условия на обмена на данните

3.1.

Общо описание на приложението EUCARIS

3.2.

Функционални и нефункционални изисквания

ГЛАВА 4:

Оценяване

1.

Процедура за оценяване съгласно член 20 (подготовка на решения в съответствие с член 25, параграф 2 от Решение 2008/615/ПВР)

1.1.

Въпросник

1.2.

Пилотно изпитване

1.3.

Посещение за оценка

1.4.

Докладване на Съвета

2.

Процедура за оценяване съгласно член 21

2.1.

Статистика и доклад

2.2.

Преразглеждане

3.

Експертни заседания

ГЛАВА 1: Обмен на ДНК данни

1.   Свързани с ДНК криминалистични въпроси, правила и алгоритми за сравняване

1.1.   Свойства на ДНК профилите

ДНК профилът може да съдържа 24 двойки числа, представляващи алелите на 24-те локуса, които също се използват в ДНК процедурите на Интерпол. Наименованията на тези локуси са показани в следната таблица:



VWA

TH01

D21S11

FGA

D8S1179

D3S1358

D18S51

Amelogenin

TPOX

CSF1P0

D13S317

D7S820

D5S818

D16S539

D2S1338

D19S433

Penta D

Penta E

FES

F13A1

F13B

SE33

CD4

GABA

Седемте отбелязани в сиво локуса на най-горния ред представляват както настоящия европейски стандартен набор от локуси (ESS), така и стандартния набор на Интерпол от локуси (ISSOL).

Правила за включване:

ДНК профилите, до които държавите-членки предоставят достъп с цел търсене и сравняване, както и ДНК профилите, изпращани с цел търсене и сравняване, трябва да съдържат поне 6 изцяло обозначени ( 1 ) локуса, като могат да съдържат допълнителни локуси или непопълнени такива в зависимост от наличността им. Референтните ДНК профили трябва да съдържат поне 6 от седемте локуса на ESS. За да се повиши точността на съвпаденията, всички налични алели се съхраняват в индексираната база данни с ДНК профили и се използват за търсене и сравняване. Всяка държава-членка следва да приложи в най-краткия практически възможен срок всеки нов вариант на ESS от локуси, приет от ЕС.

Не се допускат смесени профили, така че алелните стойности на всеки локус ще се състоят само от 2 цифри, които могат да бъдат еднакви при наличие на хомозиготност в даден локус.

При заявка за търсене с неизвестна стойност „жокер“ („wild-cards“) или с микроварианти се спазват следните правила:

— 
всички нецифрови стойности, с изключение на амелогенина, съдържащи се в профила (напр. „o“, „f“, „r“, „na“, „nr“ или „un“), се превръщат автоматично при експортирането в „жокер“ (*) и се извършва пълно търсене,
— 
цифровите стойности 0, 1 или 99, съдържащи се в профила, се превръщат автоматично при експортирането в „жокер“ (*) и се извършва пълно търсене,
— 
ако за един локус са подадени 3 алела, приема се първият алел, а останалите 2 алела се превръщат автоматично при експортирането в „жокер“ (*) и се извършва пълно търсене,
— 
когато за алел 1 или 2 е подадена стойност „жокер“ (*), се търсят и двете пермутации на цифровата стойност за локуса (напр. 12, * може да съответства на 12,14 или на 9,12 ),
— 
микровариантите на пентануклеотид (Penta D, Penta E и CD4) се сравняват по следния начин:
x.1 = x, x.1, x.2
x.2 = x.1, x.2, x.3
x.3 = x.2, x.3, x.4
x.4 = x.3, x.4, x + 1,
— 
микровариантите на тетрануклеотид (останалите локуси са тетрануклеотиди) се сравняват по следния начин:
x.1 = x, x.1, x.2
x.2 = x.1, x.2, x.3
x.3 = x.2, x.3, x + 1

1.2.   Правила за сравняване

Сравняването на 2 ДНК профила се извършва въз основа на локусите, за които и в двата ДНК профила е налице една и съща алелна двойка. В двата ДНК профила трябва да има съвпадение на поне 6 изцяло обозначени локуса (без амелогенин), преди да се изпрати отговор за наличие на съвпадение.

Пълно съвпадение (качество 1) се определя като съвпадение, когато са еднакви всички алелни стойности на сравняваните локуси, обикновено съдържащи се в искането и отговора на справка за ДНК профили. Близко съвпадение се определя като съвпадение, при което е налице различна стойност само за една от всичките сравнявани алели в двата ДНК профила (качества 2, 3 и 4). Приема се, че има близко съвпадение, само ако в двата сравнявани ДНК профила е налице съвпадение на поне 6 изцяло обозначени локуса.

Причините за близко съвпадение могат да бъдат следните:

— 
печатна грешка, допусната при ръчно въвеждане на данните за един от ДНК профилите в искането за справка или в ДНК базата данни,
— 
грешка при определянето или „извикването“ на алели в хода на процедурата за генериране на ДНК профила.

1.3.   Правила за съобщаване на резултатите

Съобщават се както пълните, така и близките съвпадения и липсата на съвпадение.

Съобщението за резултатите се изпраща на националната точка за контакт, отправила искането, като се предоставя на разположение и на националната точка за контакт, до която е отправено искането (за да може тя да прецени естеството и броя на евентуалните следващи искания за допълнителни налични лични данни и друга информация, която е свързана с ДНК профила, съответстващ на съвпадението в съответствие с членове 5 и 10 от Решение 2008/615/ПВР).

2.   Таблица на кодовите номера на държавите-членки

В съответствие с Решение 2008/615/ПВР за определяне на наименованията на домейни, както и за другите конфигуративни параметри, които се изискват от приложенията за обмен на ДНК данни по защитени мрежи съгласно договореностите от Прюм, се използва кодиране по стандарта ISO 3166-1 alpha-2.

Кодовете по ISO 3166-1 alpha-2 са следните двубуквени кодове за държавите-членки.



Имена на държавите-членки

Код

Имена на държавите-членки

Код

Белгия

BE

Люксембург

LU

България

BG

Унгария

HU

Чешката република

CZ

Малта

MT

Дания

DK

Нидерландия

NL

Германия

DE

Австрия

AT

Естония

EE

Полша

PL

Гърция

EL

Португалия

PT

Испания

ES

Румъния

RO

Франция

FR

Словакия

SK

Ирландия

IE

Словения

SI

Италия

IT

Финландия

FI

Кипър

CY

Швеция

SE

Латвия

LV

Обединеното кралство

UK

Литва

LT

 

 

3.   Функционален анализ

3.1.   Наличност на системата

Исканията по член 3 от Решение 2008/615/ПВР следва да пристигат в съответната база данни по хронологичен ред съгласно реда им на изпращане, а отговорите следва да се изпращат така че да пристигат в поискалата ги държава-членка в 15-минутен срок от пристигането на искането.

3.2.   Втори етап

Когато държава-членка получи съобщение за съвпадение, нейната национална точка за контакт отговаря за сравняването на стойностите на профила, предаден като запитване, и стойностите на профила(ите), получени като отговор, за да валидира и провери доказателствената стойност на профила. Националните точки за контакт могат да осъществяват пряк контакт помежду си с цел валидиране.

Процедурите за правна помощ започват след валидирането на съществуващо съвпадение между два профила, въз основа на получените по време на фазата за автоматизирано консултиране съобщения за „пълно съвпадение“ и „близко съвпадение“.

4.   Документ за контрол на интерфейса при обмен на ДНК данни

4.1.   Въведение

4.1.1.    Цели

В тази глава се определят изискванията за обмена на информация за ДНК профили между системите от ДНК бази данни на всички държави-членки. Полетата в заглавната част са дефинирани специално за целите на обмена на ДНК данни по линия на Прюм, а съдържащата данните част е разработена на базата на частта за данните за ДНК профили в XML-схемата, дефинирана за електронния портал на Интерпол за обмен на ДНК данни.

Данните се обменят чрез SMTP (Simple Mail Transfer Protocol) и други модерни технологии, като се използва сървър за централизирано предаване на съобщенията, предоставен от доставчика на мрежови услуги. XML-файлът се транспортира в съдържателната част на съобщението.

4.1.2.    Обхват

Този ICD определя само съдържанието на съобщението. Всички специфични за мрежата и съобщението въпроси, се дефинират еднообразно, за да се осигури обща техническа база за обмен на ДНК данни.

Това включва:

— 
формáта на полето „предмет“ на съобщението, за да може да се осъществи автоматизираната обработка на съобщенията,
— 
дали е необходимо да се криптира съдържанието и ако е така, кои методи следва да се изберат,
— 
максималната дължина на съобщението.

4.1.3.    XML-структура и принципи

Съобщението във XML-формат е структурирано в:

— 
заглавна част, в която се съдържа информация относно параметрите на предаване и
— 
част за данните, в която се съдържа специфична информация за профила, както и самият профил.

За исканията и за отговорите се използва една и съща XML-схема.

За да могат да се правят изчерпателни проверки на неидентифицирани ДНК профили (член 4 от Решение 2008/615/ПВР), е възможно да се изпращат по няколко профила в едно съобщение. Максималният брой на профилите в едно съобщение трябва да бъде определен. Броят им зависи от максималния допустим размер на съобщенията и се определя след избора на пощенски сървър.

XML пример:

<?version="1.0" standalone="yes"?>

<PRUEMDNAx xmlns:msxsl="urn:schemas-microsoft-com:xslt"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<header>

(…)

</header>

<datas>

(…)

</datas>

[<datas> структурата на данните се повтаря, когато се изпращат повече профили (….) в едно SMTP-съобщение, разрешено само за случаите по член 4

</datas>]

</PRUEMDNA>

4.2.   Дефиниране на XML-структурата

Следните дефиниции са само за целите на документирането и по-добрата четивност, а информацията със задължителен характер се дава във файла с XML-схема (PRUEM DNA.xsd).

4.2.1.    Схема PRUEMDNAx (Schema PRUEMDNAx)

Тази схема съдържа следните полета:



Fields

Type

Description

header

PRUEM_header

Occurs: 1

datas

PRUEM_datas

Occurs: 1 … 500

4.2.2.    Съдържание на заглавната структура

4.2.2.1. Заглавна част PRUEM (PRUEM header)

Тази структура описва заглавната част на XML-файла. Тя съдържа следните полета:



Fields

Type

Description

direction

PRUEM_header_dir

Direction of message flow

ref

String

Reference of the XML file

generator

String

Generator of XML file

schema_version

String

Version number of schema to use

requesting

PRUEM_header_info

Requesting Member State info

requested

PRUEM_header_info

Requested Member State info

4.2.2.2. PRUEM_header dir

Тип данни, съдържащи се в съобщението — възможни стойности:



Value

Description

R

Request

A

Answer

4.2.2.3. PRUEM header info

Структура, описваща държавата-членка и датата/часа на съобщението. Съдържа следните полета:



Fields

Type

Description

source_isocode

String

ISO 3166-2 code of the requesting Member State

destination_isocode

String

ISO 3166-2 code of the requested Member State

request_id

String

unique Identifier for a request

date

Date

Date of creation of message

time

Time

Time of creation of message

4.2.3.    Съдържание на данните за профили по линия на Прюм (PRUEM Profile data)

4.2.3.1. Данни по линия на Прюм (PRUEM_datas)

Тази структура описва частта за данни за профила на XML-файла. Съдържа следните полета:



Fields

Type

Description

reqtype

PRUEM request type

Type of request (Article 3 or 4)

date

Date

Date profile stored

type

PRUEM_datas_type

Type of profile

result

PRUEM_datas_result

Result of request

agency

String

Name of corresponding unit responsible for the profile

profile_ident

String

Unique Member State profile ID

message

String

Error Message, if result = E

profile

IPSG_DNA_profile

If direction = A (Answer) AND result ≠ H (Hit) empty

match_id

String

In case of a HIT PROFILE_ID of the requesting profile

quality

PRUEM_hitquality_type

Quality of Hit

hitcount

Integer

Count of matched Alleles

rescount

Integer

Count of matched profiles. If direction = R (Request), then empty. If quality! = 0 (the original requested profile), then empty.

4.2.3.2. Тип искане по линия на Прюм (PRUEM_request_type)

Тип данни, съдържащи се в съобщението — възможни стойности:



Value

Description

3

Requests pursuant to Article 3 of Decision 2008/615/JHA

4

Requests pursuant to Article 4 of Decision 2008/615/JHA

4.2.3.3. Тип качество на съвпадения по линия на Прюм (PRUEM_hitquality_type)



Value

Description

0

Referring original requesting profile:

Case „No Hit“: original requesting profile sent back only;

Case „Hit“: original requesting profile and matched profiles sent back.

1

Equal in all available alleles without wildcards

2

Equal in all available alleles with wildcards

3

Hit with Deviation (Microvariant)

4

Hit with mismatch

4.2.3.4. Тип данни по линия на Прюм (PRUEM_data_type)

Тип данни, съдържащи се в съобщението — възможни стойности:



Value

Description

P

Person profile

S

Stain

4.2.3.5. PRUEM_data_result

Тип данни, съдържащи се в съобщението — възможни стойности:



Value

Description

U

Undefined, If direction = R (request)

H

Hit

N

No Hit

E

Error

4.2.3.6. IPSG_DNA_profile

Структура, описваща ДНК профил. Съдържа следните полета:



Fields

Type

Description

ess_issol

IPSG_DNA_ISSOL

Group of loci corresponding to the ISSOL (standard group of Loci of Interpol)

additional_loci

IPSG_DNA_additional_loci

Other loci

marker

String

Method used to generate of DNA

profile_id

String

Unique identifier for DNA profile

4.2.3.7. IPSG_DNA_ISSOL

Структура, съдържаща локусите на ISSOL (стандартния набор на Интерпол от локуси). Съдържа следните полета:



Fields

Type

Description

vwa

IPSG_DNA_locus

Locus vwa

th01

IPSG_DNA_locus

Locus th01

d21s11

IPSG_DNA_locus

Locus d21s11

fga

IPSG_DNA_locus

Locus fga

d8s1179

IPSG_DNA_locus

Locus d8s1179

d3s1358

IPSG_DNA_locus

Locus d3s1358

d18s51

IPSG_DNA_locus

Locus d18s51

amelogenin

IPSG_DNA_locus

Locus amelogin

4.2.3.8. IPSG_DNA_additional_loci

Структура, съдържаща другите локуси. Съдържа следните полета:



Fields

Type

Description

tpox

IPSG_DNA_locus

Locus tpox

csf1po

IPSG_DNA_locus

Locus csf1po

d13s317

IPSG_DNA_locus

Locus d13s317

d7s820

IPSG_DNA_locus

Locus d7s820

d5s818

IPSG_DNA_locus

Locus d5s818

d16s539

IPSG_DNA_locus

Locus d16s539

d2s1338

IPSG_DNA_locus

Locus d2s1338

d19s433

IPSG_DNA_locus

Locus d19s433

penta_d

IPSG_DNA_locus

Locus penta_d

penta_e

IPSG_DNA_locus

Locus penta_e

fes

IPSG_DNA_locus

Locus fes

f13a1

IPSG_DNA_locus

Locus f13a1

f13b

IPSG_DNA_locus

Locus f13b

se33

IPSG_DNA_locus

Locus se33

cd4

IPSG_DNA_locus

Locus cd4

gaba

IPSG_DNA_locus

Locus gaba

4.2.3.9. IPSG_DNA_locus

Структура, описваща локус. Съдържа следните полета:



Fields

Type

Description

low_allele

String

Lowest value of an allele

high_allele

String

Highest value of an allele

5.   Архитектура на приложението, сигурността и комуникациите

5.1.   Обзорен преглед

При внедряването на приложенията за обмен на ДНК данни в рамките на Решение 2008/615/ПВР се използва обща комуникационна мрежа, която е логически затворена между държавите-членки. С цел експлоатиране по по-ефективен начин на тази обща комуникационна инфраструктура за изпращане на искания и получаване на отговори се възприема асинхронен механизъм за предаване на исканията за ДНК данни и дактилоскопични данни в капсулирани SMTP-електронни съобщения. С цел да се удовлетворят изискванията за сигурност, като разширение на SMTP-функционалността ще се използва механизъм sMIME, за да се установи действително затворен сигурен „тунел“ за работата в мрежата.

Оперативната TESTA (трансевропейски телематични услуги между администрациите) се използва за комуникационна мрежа за обмена на данни между държавите-членки. TESTA се управлява от Европейската комисия. С оглед на факта, че националните ДНК бази данни и действащите национални точки за достъп до TESTA могат да бъдат разположени на различни места в държавите-членки, достъпът до TESTA може да се осигури, като:

1. 

се използват съществуващите национални точки за достъп или се създаде нова национална точка за достъп до TESTA; или

2. 

се създаде защитена местна връзка от обекта, където е разположена ДНК базата данни, управлявана от компетентната национална служба, до съществуващата национална точка за достъп до TESTA.

Протоколите и стандартите, внедрени в приложенията, използвани за изпълнението на Решение 2008/615/ПВР, съответстват на отворените стандарти и отговарят на изискванията, наложени от органите, определящи националната политиката по отношение на сигурността в държавите-членки.

5.2.   Архитектура на горното ниво

В обхвата на Решение 2008/615/ПВР всяка държава-членка ще прави налични нейните ДНК данни за целите на обмена на такива данни и/или търсения в тях от други държави-членки в съответствие със стандартизирания общ формат на данните. Архитектурата е снована на комуникационен модел, при който се осъществява връзка „от всеки до всеки“. Не съществува централен компютърен сървър, нито централизирана база данни за съхранение на ДНК профили.

Фигура 1: Топология на обмена на ДНК данни

image

Освен спазването на националните правни ограничения, касаещи съответните обекти в държавите-членки, всяка държава-членка може да реши какъв вид хардуер и софтуер следва да се внедри за конфигуриране в съответния обект, така че да са спазени изискванията на Решение 2008/615/ПВР.

5.3.   Стандарти за сигурност и защита на данните

Три са нивата на сигурност, които са взети под внимание и са въведени.

5.3.1.    На ниво данни

Предоставяните от държавите-членки данни за ДНК профили трябва да се изготвят в съответствие с общите стандарти за защита на данните, така че отправилата искането държава-членка да получи отговор, в който основно се посочва наличие на попадение или липса на попадение (HIT/NO-HIT) заедно с идентификационен номер в случай на попадение, но в него не се съдържа никаква лична информация. По-нататъшното разследване след уведомяване за наличие на попадение се води на двустранно равнище съгласно съществуващите национални правни и организационни разпоредби, уреждащи съответните обекти в държавите-членки.

5.3.2.    На ниво комуникация

Съобщенията, съдържащи информация за ДНК профили (искания и отговори), се криптират посредством най-модерен механизъм в съответствие с отворените стандарти, като sMIME, преди да се изпратят в съответните обекти в държавите-членки.

5.3.3.    На ниво предаване

Всички криптирани съобщения, съдържащи информация за ДНК профили, се изпращат в обектите на другите държави-членки посредством виртуална частна тунелираща система администрирана от надежден доставчик на мрежови услуги на национално равнище и връзките за сигурност към тази тунелираща система са под национално управление. Виртуалната частна тунелираща система няма никакъв точка на контакт с откритата интернет мрежа.

5.4.   Протоколи и стандарти, които да се използват за механизма за криптиране sMIME и свързани пакети

Отвореният стандарт sMIME, като разширение на действащия de facto стандарт за електронна поща SMTP, ще се внедри за криптиране на съобщения, съдържащи информация за ДНК профили. Протоколът sMIME (V3) позволява електронно подписана разписка, етикети за сигурност и защитени списъци с електронни адреси (mailing lists), като е базиран върху „пласта“ на Cryptographic Message Syntax (CMS), IETF спецификация за защитени чрез криптиране съобщения. Той може да се използва за електронно подписване, резюмиране, автентификация или криптиране на всякакви форма цифрови данни.

Сертификатът, на базата на който се прилага механизмът sMIME, трябва да съответства на стандарта X.509. С цел да се осигурят стандарти и процедури, които са общи с тези за други приложения, използвани по линия на Прюм, правилата за обработване за операциите по криптиране на базата на sMIME или за прилагане в различни видове среда на базата на готови търговски продукти (Commercial Product of the Shelves — COTS), са следните:

— 
последователността на операциите е: първо криптиране и след това подписване,
— 
за симетрично и асиметрично криптиране се прилагат съответно алгоритмите за криптиране AES (Advanced Encryption Standard) с 256-битов ключ и RSA с 1 024 -битов ключ,
— 
прилага се hash-алгоритъм SHA-1.

Функционалността s/MIME е вградена в повечето съвременни софтуерни пакети за електронна поща, в т.ч. Outlook, Mozilla Mail и Netscape Communicator 4.x, като позволява оперативна съвместимост между повечето основни софтуерни пакети за електронна поща.

Поради лесното интегриране на sMIME в националната ИТ инфраструктура във всички държави-членки, този механизъм е избран като подходящ с цел осигуряване на сигурността на ниво комуникации. С цел по-ефикасен „тест на концепцията“ („Proof of Concept“) и намаляване на разходите обаче е избран стандартът JavaMail API, с който да се извърши прототипирането на обмена на ДНК данни. JavaMail API предоставя елементарно криптиране и декриптиране на електронни съобщения посредством s/MIME и/или OpenPGP. Целта е да се осигури прост и лесен за употреба програмно-приложен интерфейс (API) за клиентите на електронна поща, които желаят да изпращат и получават криптирани електронни съобщения в един от двата най-популярни формата за криптиране на електронни съобщения. Следователно, за да са изпълнени изискванията на Решение 2008/615/ПВР, ще е достатъчно високотехнологично внедряване на базата на JavaMail API, като например продуктът на Bouncy Castle JCE (Java Cryptographic Extension), който ще се използва за въвеждането на sMIME за прототипирането на обмена на ДНК данни между държавите-членки.

5.5.   Архитектура на приложението

Всяка държава-членка ще предостави на другите държави-членки набор от стандартизирани данни за ДНК профили, които съответстват на използвания в момента общ документ за контрол на интерфейса (ICD). Това може да стане или чрез предоставяне на логически поглед върху индивидуалната национална база данни, или чрез установяване на физически експортирана база данни (индексирана база данни).

Четирите основни компонента: сървърът за електронна поща/sMIME, сървърът за приложението, зоната на структурирани данни (Data Structure Area) за извличане/подаване на данни и регистрация на входящите/изходящите съобщения, както и търсачката за стравняване, внедряват цялостната логика на приложението по начин, който не зависи от конкретните продукти.

За да се осигури на всички държави-членки възможност да интегрират лесно тези компоненти в съответните си национални обекти, конкретно определената обща функционалност е внедрена посредством компоненти с отворен код, които могат да се избират от всяка държава-членка в зависимост от нейната национална политика и уредба в областта на ИТ. Поради независимите характеристики на внедряваната система за получаване на достъп до индексирани бази данни с ДНК профили, обхванати от Решение 2008/615/ПВР, всяка държава-членка може свободно да избира собствената си хардуерна и софтуерна платформа, включително системите за бази данни и операционните системи.

Прототипът за обмена на ДНК данни е разработен и успешно изпитан в съществуващата обща мрежа. Вариант 1.0 е внедрен в работната среда и се използва за ежедневната дейност. Държавите-членки могат да използват разработения съвместно продукт, но също така могат да разработят свои продукти. Компонентите на общия продукт ще се поддържат, приспособяват и доразвиват в съответствие с изменящите се изисквания за функционалност по отношение на ИТ, криминалистиката и/или полицейската работа.

Фигура 2: Обща топология на приложението

image

5.6.   Протоколи и стандарти, които да се използват за архитектурата на приложението

5.6.1.    XML

Обменът на ДНК данни ще използва изцяло XML-схемата като ги прикачва към SMTP-електронни съобщения. Езикът XML (eXtensible Markup Language) се препоръчва от консорциума World Wide Web (W3C) като общофункционален метаезик за създаване на специализирани метаезици, способни да описват множество различни видове данни. Описанието на ДНК профила, който е подходящ за обмен между всички държави-членки, е изготвено посредством XML и XML-схема в ICD.

5.6.2.    ODBC

ODBC (Open DataBase Connectivity) предоставя стандартен софтуерен API метод за достъп до системи за управление на бази данни, който е независим от езиците за програмиране, от системите за базите данни и операционните системи. ODBC обаче си има своите недостатъци. Администрирането на голям брой клиентски машини може да е свързано с разнообразие на драйверите и DLL файловете. Това усложнение може да повиши разходите за администриране на системата.

5.6.3.    JDBC

JDBC (Java DataBase Connectivity) представлява API за програмния език Java, който определя какъв достъп има клиентът до базата данни. За разлика от работата с ODBC, при JDBC не се изисква да се използва даден набор от местни DLL файлове на десктопа.

Работната логика на обработката на искания и отговори за ДНК профили в съответния обект на всяка държава-членка е описана в дадената по-долу диаграма. Потоците на исканията и на отговорите взаимодействат с неутрална зона за данни, която обхваща различни масиви с еднакво структурирани данни.

Фигура 3: Обща картина на работните потоци в приложенията в съответния обект на всяка държава-членка