HGO883/2011
Внутренний номер:  341136
Varianta în limba de stat
Карточка документа

Республика Молдова
ПРАВИТЕЛЬСТВО
ПОСТАНОВЛЕНИЕ Nr. 883
от  25.11.2011
об утверждении Технического концепта
автоматизированной информационной системы
«Государственный регистр контролеров
 персональных данных»
Опубликован : 09.12.2011 в Monitorul Oficial Nr. 216-221     статья № : 976
    На основании пункта 1) статьи 22 Закона № 467-XV от 21 ноября 2003 года об информатизации и государственных информационных ресурсах (Официальный монитор Республики Молдова, 2004 г., № 6-12, ст.44), с последующими изменениями, Правительство ПОСТАНОВЛЯЕТ:
    1. Утвердить Технический концепт автоматизированной информационной системы «Государственный регистр контролеров персональных данных» (прилагается).
    2. Национальному центру по защите персональных данных:
вести и администрировать автоматизированную информационную систему «Государственный регистр контролеров персональных данных»;
разработать и до 20 марта 2012 года представить на рассмотрение проект постановления Правительства об утверждении положения о Государственном регистре контролеров персональных данных.
    3. Финансирование создания и внедрения автоматизированной информационной системы учета контролеров персональных данных осуществлять за счет и в пределах ассигнований, утвержденных в Законе о государственном бюджете Государственной канцелярии для внедрения Проекта «е-Преобразование Правительства», а также на основании финансовых средств иностранных доноров.
    4. Министерству информационных технологий и связи зарегистрировать в установленном порядке информационный ресурс «Государственный регистр контролеров персональных данных».

    ПРЕМЬЕР-МИНИСТР                                                              Владимир ФИЛАТ

    Контрасигнуют:
    министр информационных
    технологий и связи                                                                     Павел ФИЛИП
    министр финансов                                                                      Вячеслав НЕГРУЦА

    № 883. Кишинэу, 25 ноября 2011 г.

Утвержден
Постановлением Правительства
№ 883 от 25 ноября 2011 г.

ТЕХНИЧЕСКИЙ КОНЦЕПТ
автоматизированной информационной системы
«Государственный регистр контролеров персональных данных»
Раздел I. Общие положения
    Технический концепт автоматизированной информационной системы «Государственный регистр контролеров персональных данных» является переложением статьи 21 Директивы 95/46 ЕС Европейского Парламента и Совета от 24 октября 1995 года о защите прав частных лиц, применительно к обработке персональных данных и о свободном движении этих данных, опубликованной в Официальном журнале европейских сообществ (JOCE) № L 281 от 23 ноября 1995 г.
    1. Определение системы
    1) Государственный регистр контролеров персональных данных (в дальнейшем – Регистр) представляет собой информатическую систему, главной целью которой является автоматизация работы Национального центра по защите персональных данных (в дальнейшем – Центр) для учета всех контролеров персональных данных, а также баз данных, информационных и информатических систем, в которых хранятся и обрабатываются персональные данные.
    2) Регистр является ключевым инструментом Центра, посредством которого будут осуществляться следующие цели:
    a) обеспечение надлежащего уровня защиты персональных данных в Республике Молдова;
    b) регистрация и учет всех контролеров персональных данных, а также баз данных, информационных и информатических систем, в которых обрабатываются персональные данные;
    c) обеспечение права на информацию субъектов персональных данных и любого лица, запрашивающего информацию;
    d) предоставление качественных услуг контролерам персональных данных.
    2. Назначение системы
    1) Регистр обеспечит возможность приема и обработки в режиме он-лайн обращений контролеров персональных данных относительно регистрации, изменения или удаления информации о базах данных, информационных и информатических системах, в которых хранятся и обрабатываются персональные данные.
    2) Для субъектов персональных данных, центральных и местных публичных органов власти, юридических лиц и т.д. Регистр будет ключевым информационным ресурсом по предоставлению публичной информации относительно контролеров персональных данных, авторизированных для обработки персональных данных, баз данных, информационных и информатических систем, в которых обрабатываются персональные данные.
    3) Для Центра Регистр будет ключевым инструментом, автоматизирующим его работу. Регистр будет способствовать получению и обработке он-лайн обращений от контролеров персональных данных и субъектов персональных данных, выдаче решений, обобщению отчетов по анализу и мониторингу ситуации на текущий день.
    3. Основные понятия
    1) В настоящем Концепте используются следующие термины и определения:
   орган публичной власти – любая организационная структура или любой орган, учрежденный законом или иным нормативным актом, функционирующий в режиме публичной власти в целях реализации общественного интереса;
    креденциалы – набор атрибутов, которые идентифицируют личность и аутентифицируют пользователей и системы в рамках информационных систем;
  данные – основные единицы информации о людях, фактах, событиях, явлениях, процессах, объектах, ситуациях и т.д., представленные в форме, которая позволяет нотифицировать, комментировать и обрабатывать их;
    целостность данных – состояние данных, когда они сохраняют свое содержание и однозначность толкования в условиях влияния случайных факторов. Считается, что данные сохраняют свою целостность, если они не искажены и не разрушены (не стерты);
   протоколирование – функция по регистрации информации о событиях. В рамках информационных систем записи о событиях включают подробности о дате и времени, пользователе, предпринятом действии;
    M-Cloud – стратегия Центра электронного управления по порядку технологической консолидации информационных услуг;
    метаданные – метод присвоения семантической ценности данных, хранящихся в базе данных (данные о данных);
    информационный объект – виртуальное отображение реально существующих субъектов, как материальных, так и не материальных;
    информационная система – совокупность методов и средств сбора, обработки и передачи информации, необходимой для процесса управления (включает мануальные и автоматизированные технологии обработки данных);
  автоматизированная информационная система (информатическая система) – совокупность программ и оборудования, обеспечивающих автоматическую обработку данных (автоматизированный компонент информационной системы);
    информационные и коммуникационные технологии – общий термин, включающий все технологии, используемые для обмена и манипулирования информацией;
    достоверность данных – уровень соответствия данных, хранящихся в памяти компьютера или в документах, реальному состоянию объектов конкретной области системы, отображаемых этими данными.
    4. Цель и задачи системы
    1) Основное назначение Регистра заключается в обеспечении Центра передовым информационным решением, используемым в качестве подспорья для деятельности Центра в целях выполнения положений  правовой базы в области защиты персональных данных.
    2) При этом информационная система будет выполнять автоматическую валидацию отправленных контролерами персональных данных обращений по регистрации, изменению, удалению информации из Регистра. Информационное решение будет автоматически регистрировать совокупность действий, выполняемых пользователями, с подробной регистрацией данных, параметров информации и запрашиваемых обращений.
    3) Главное преимущество Регистра состоит в том, что в перспективе каждый контролер персональных данных сможет посредством веб-интерфейса отправлять обращения на выполнение операций по регистрации, изменению/удалению из Регистра и получать решения об утверждении или отклонении отправленных обращений.
    4) Для лиц, запрашивающих информацию, Регистр будет предоставлять публичный веб-интерфейс, который позволит доступ и просмотр публичной информации о контролерах персональных данных и их информационных или информатических системах.
    5) В результате, среди основных задач разработанного информационного решения следует отметить:
    a) проектирование и внедрение современных технологий взаимодействия между контролерами персональных данных, лицами, запрашивающими информацию, субъектами персональных данных и Центром;
    b) обеспечение возможности работы в сети для эффективного использования общих ресурсов путем реализации многоуровневой архитектуры клиент-сервер;
    c) увеличение скорости обмена информацией, сокращение продолжительности цикла валидации и обработки обращений по регистрации, изменению, удалению и времени ответа;
    d) эффективное и широкое использование компьютеров, которыми располагает Центр;
    e) контроль доступа к данным и обеспечение максимальной безопасности и конфиденциальности собранных данных, не являющихся публичными, и пользователей.
    5. Основные принципы системы
    1) При проектировании, разработке и внедрении автоматизированной информационной системы необходимо учитывать следующие общие принципы:
    a) принцип законности: предполагает создание и функционирование автоматизированной информационной системы в соответствии с национальным законодательством и международными нормами и стандартами, признанными в данной области;
    b) принцип разделения архитектуры на уровни: заключается в независимой разработке подсистем Регистра в соответствии со стандартами межуровневого интерфейса;
    c) принцип независимости платформы: пользовательский интерфейс автоматизированной информационной системы не требует определенной программной или аппаратной платформы для компьютера пользователя;
    d) принцип достоверных данных: предусматривает ввод данных в систему только посредством авторизованных и аутентифицированных каналов;
    e) принцип информационной безопасности: предполагает адекватный уровень селективности, целостности, доступности и эффективности для защиты данных от потерь, ухудшения, повреждения и несанкционированного доступа;
    f) Принцип доступа к публичной информации: предусматривает осуществление процедур по обеспечению доступа лиц, запрашивающих информацию публичного характера, представляемую информационным решением.
    g) принцип прозрачности: предусматривает разработку и осуществление, согласно модульному принципу, с использованием прозрачных стандартов в области информационных технологий и телекоммуникаций;
    h) принцип расширения: предусматривает возможность расширения и дополнения автоматической информационной системы  новыми функциями или усовершенствования уже существующих функций;
    i) принцип приоритетности первого лица/единого центра: предполагает существование ответственного лица высокого ранга с достаточными правами для принятия решений и координации деятельности в целях создания и функционирования системы;
    j) принцип масштабности: предполагает обеспечение константной производительности компьютеризированного решения при увеличении объемов данных и обращений к информационной системе;
    k) принцип простоты и удобства использования: предусматривает разработку и осуществление всех приложений, технических и программных средств, доступных для пользователей системы, основанных исключительно на визуальных, эргономических и логических принципах.
    2) В частности, для автоматической информационной архитектуры системы необходимо соблюдение следующих приоритетных принципов:
    a) внедрение как минимум 3-уровневого клиент-серверского  решения;
    b) внедрение решений, которые предоставят веб-интерфейс для каждого пользователя Регистра;
    c) обеспечение адекватной безопасности системы для защиты информации и компонентных подсистем от несанкционированного использования или разглашения информации о персональных данных или информации, доступ к которой ограничен;
    d) признание информации в качестве имущества и ее надлежащее администрирование;
    e) разработка и внедрение ИТ-систем, позволяющих их повторно использовать для других процессов или для обеспечения условий для разработки новых функциональных возможностей;
    f) минимизация числа различных технологий и продуктов, которые предлагают те же функциональные возможности или аналогичные по назначению;
    g) обеспечение эффективной скорости обработки обращений бенефициаров;
    h) обеспечение аварийного восстановления для полученного ИТ-решения (обеспечения физической безопасности информационного решения) как составной части плана внедрения.
    6. Задачи, реализуемые системой
    Внедрение Регистра в Центре позволит модернизировать информационную систему за счет автоматизации деятельности существующих подразделений Центра, а также ряда ожидаемых преимуществ  как  следствие внедрения и эксплуатации Регистра:
    a) повышение эффективности и прозрачности деятельности Центра;
    b) уменьшение неудобств, связанных с процессом приема обращений по регистрации, изменению или удалению данных из Регистра
    c) обеспечение электронного обмена данными с третьими лицами;
    d) популяризация услуг по информированию и обслуживанию обращений в режиме он-лайн;
    e) снижение затрат на обработку обращений, полученных от контролеров персональных данных;
    f) снижение затрат, связанных с обработкой информации на традиционных материалах (бумаге), за счет перехода на исключительно цифровую обработку информации.
Раздел II. Нормативно-правовое пространство
функционирования системы
    1) Нормативно-законодательную базу, которая будет способствовать реализации Регистра, составляет действующее национальное законодательство, международные договоры и соответствующие международные и европейские рекомендации в данной области.
    2) Создание и функционирование информационной системы регламентируются следующими нормативными и законодательными актами:
    a) Конвенция о защите частных лиц в отношении автоматизированной обработки данных личного характера, заключенная в Страсбурге 28 января 1981 г.;
    b) Дополнительный протокол к Конвенции о защите физических лиц в отношении автоматизированной обработки данных личного характера, касательно органов контроля и трансграничного перемещения персональных данных, принятый в Страсбурге 8 ноября 2001 г.;
    c) Закон № 171-XIII от 6 июля 1994 года о коммерческой тайне (Официальный монитор Республики Молдова, 1994 г., № 13, ст.126);
    d) Закон № 982-XIV от 11 мая 2000 года о доступе к информации (Официальный монитор Республики Молдова, 2000 г., № 88-90, ст. 664);
    e) Закон № 1069-XIV от 22 июня 2000 года об информатике (Официальный монитор Республики Молдова, 2001 г., № 73-74, ст.547);
    f) Закон № 467-XV от 21 ноября 2003 года об информатизации и государственных информационных ресурсах (Официальный монитор Республики Молдова, 2004 г., № 6-12, ст.44);
    g) Закон № 264-XV от 15 июля 2004 года об электронном документе и цифровой подписи (Официальный монитор Республики Молдова, 2004 г., №132-137, ст.710);
    h) Закон № 71-XVI от 22 марта 2007 года о регистрах (Официальный монитор Республики Молдова, 2007 г., № 70-73, ст.314);
    i) Закон № 241-XVI от 15 ноября 2007 года об электронных коммуникациях (Официальный монитор Республики Молдова, 2008 г., № 51-54, ст. 155);
    j) Закон № 245-XVI от 27 ноября 2008 года о государственной тайне (Официальный монитор Республики Молдова, 2009 г., № 45-46, ст.123);
    k) Закон №133 от 8 июля 2011 года о защите персональных данных (Официальный монитор Республики Молдова, 2011 г., № 170-175, ст.492);
    l) Постановление Правительства № 735 от 11 июня 2002 г. «О специальных телекоммуникационных системах Республики Молдова»  (Официальный монитор Республики Молдова, № 79-81, ст.833);
    m) Постановление Правительства №632 от 8 июня 2004 г. «Об утверждении Политики создания информационного общества в Республике Молдова» (Официальный монитор Республики Молдова, 2004 г., № 96-99, ст.789);
    n) Постановление Правительства № 840 от 26 июля 2004 г. «О создании телекоммуникационной системы органов публичного управления» (Официальный монитор Республики Молдова, 2004 г., № 130, ст.1013);
    o) Постановление Правительства № 255 от 9 марта 2005 г. «О Национальной стратегии создания информационного общества – «Электронная Молдова» (Официальный монитор Республики Молдова, 2005 г., № 46-50, ст.336);
    p) Постановление Правительства № 945 от 5 сентября 2005 г. «О центрах сертификации открытых ключей» (Официальный монитор Республики Молдова, 2005 г., № 123-125, ст.1020);
    q) Постановление Правительства № 320 от 28 марта 2006 г. «Об утверждении Положения о порядке применения цифровой подписи в электронных документах органов публичной власти» (Официальный монитор Республики Молдова, 2006 г., № 51-54, ст.350);
    r) Постановление Правительства № 733 от 28 июня 2006 г. «О Концепции электронного правления» (Официальный монитор Республики Молдова, 2006 г., № 106-111,ст. 799);
    s) Постановление Правительства № 916 от 6 августа 2007г. «Об утверждении Концепции Правительственного портала» (Официальный монитор Республики Молдова, 2007 г., №127-130, ст.952;
    t) Постановление Правительства № 1123 от 14 декабря 2010 г. «Об утверждении Требований по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» (Официальный монитор Республики Молдова, 2010 г., № 254-256, ст.1282);
    u) Приказ Министерства информационных технологий и связи № 94 от 17 сентября 2009 года об утверждении некоторых технических регламентов (порядок учета электронных публичных услуг, предоставление электронных публичных услуг, обеспечение информационной безопасности при предоставлении электронных публичных услуг, определение стоимости разработки и внедрения автоматизированных информационных систем) (Официальный монитор Республики Молдова, 2010 г., № 58-60, ст.952);
    v) Стандарт Республики Молдова SMV ISO CEI 15288:2009  «Проектирование систем и программного обеспечения. Процессы жизненного цикла системы»;
    w) Технический регламент «Процессы жизненного цикла программного обеспечения» RT 38370656-002:2006 (Официальный монитор Республики Молдова, 2006 г.,  № 95-97, ст.335);
    x) другие законы, нормативные акты, стандарты, действующие в области ИКТ.
    3) В соответствии со статьей 11 Закона № 467-XV от 21 ноября 2003 года об информатизации и государственных информационных ресурсах, Регистр представляет собой государственный информационный ресурс и в этом случае, согласно статье 21 того же закона, необходимо учитывать политику в сфере государственных информационных ресурсов, разработанную Министерством информационного развития и утвержденную Правительством. В соответствии со статьей 19 того же закона, необходима сертификация Регистра и регистрация его в Регистре государственных информационных ресурсов и систем, находящихся в ведении Министерства информационных технологий и связи. В результате регистрации владельцу будут выдаваться идентификатор информатической системы.
    4) Являются объектами учета и контроля в Регистре контролеры персональных данных, их информационные и информатические системы согласно компонентам, установленным Законом №133 от 8 июля 2011 года о защите персональных данных.
    5) В контексте обеспечения доступа граждан к информации из информационных государственных ресурсов или оказание услуг со стороны государственных органов при помощи мультимедийных устройств и электронных средств было разработано и принято Постановление Правительства №916 от 6 августа 2007 г. «Об утверждении Концепции Правительственного портала», которое устанавливает определенные требования и стандарты для обеспечения эффективного, оперативного и качественного информационного взаимодействия, между компонентами общества (Правительство, граждане, бизнес, гражданское общество). Это постановление предусматривает, что взаимодействие между государственными органами и гражданами и бизнесом в процессе предоставления государственных услуг в электронной форме должно быть сделано через один правительственный шлюз - так называемый «правительственный портал».
    6) Правительственный портал является инструментом поддержки в деятельности по электронному правлению, обеспечивающим возможность обмена информацией между физическими и юридическими лицами и органами публичного управления посредством ком­муникационных сетей, включая Интернет, и представляет собой точку доступа к информационным услугам.
    7) В концепции о Правительственном портале отражается и видение касательно способа доступа и предоставления информации гражданам, экономическим агентам или другим категориям пользователей. Так, Правительственный портал предоставляет в распоряжение пользователей инструмент для доступа к  многочисленным услугам, предоставляемым органами публичной власти по принципу единого окна, а предоставление информации позволит гражданам пользоваться единой системой государственной идентификации, получить доступ к целому ряду услуг, предоставляемых Порталом, без необходимости использования отдельных аутентификационных данных для каждой отдельной электронной услуги.
    8) Основными выводами, вытекающими из концепции о Правительственном портале, которые должны приниматься во внимание при разработке Регистра, являются:
    a) любая электронная информация или услуга, предоставляемая гражданам публичными органами, должна быть доступна и через Правительственный портал;
    b) использование единой системы государственной идентификации для всех услуг, доступных на Правительственном портале.
Раздел III. Функциональное пространство системы
    7. Архитектура системы
    1) Автоматическая информационная система обеспечит пользователю веб-интерфейс для доступа к Регистру, доступный  посредством интернет-браузера. С функциональной точки зрения будет реализовано надежное и масштабируемое решение как в результате увеличения числа пользователей, одновременно использующих ресурсы Регистра, так и в случае увеличения объема информации, управляемого им.
    2) Поскольку информационные системы органов публичной власти не изолированы, а взаимодействуют между собой, информационное решение будет предоставлять поддержку для интеграции с другими информационными подсистемами и приложениями, использующими веб-сервисы - метод, технически приравниваемый к современным тенденциям в целях сотрудничества в процедурах рассмотрения обращений или распространения информации.
    3) Вследствие того, что характер информации, которая обрабатывается и хранится в Регистре, является как публичным,  так и с ограниченным доступом, информационное решение позволит использовать защищенное соединение между клиент-станцией и сервером приложения.
    4) Принимая во внимание цели и функциональные свойства Регистра, целесообразно внедрение минимум 3-уровневой архитектуры клиент-сервер. Реализация 3-уровневой клиент-серверной архитектуры для Регистра обеспечит вероятность того, что уровень клиент (наиболее зависимый от программной платформы и от аппаратного обеспечения) будет легко реализован посредством Интернет-обозревателя. В этом случае исчезает зависимость от установленной платформы на клиентском компьютере (пользователи смогут работать как на UNIX- станциях, так и на Windows-станциях).
    5) Границы между уровнями являются логическими, а не физическими, что предоставляет возможность запуска на одном и том же компьютере-сервере. Условием является то, что система должна быть хорошо структурирована, границы строго определенны для каждого уровня и практически представлены интерфейсами состоящих объектов. Они накладываются менеджером системы в зависимости от определенных условий для каждого приложения.
    6) Как показано на рис.1, архитектура Регистра определяется четырьмя контурами:
    a) внутренний контур Центра, который включает как серверы, на которых располагаются компоненты Регистра, так и рабочие станции сотрудников и информационную инфраструктуру Центра;
  b) контур контролера персональных данных, который находится на расстоянии и использует свои вычислительные ресурсы для отправки обращения по выполнению регистрации/изменения/удаления в/из Регистра через Интернет;
    c) контур органов публичной власти, которых множество и которые представляют их информационные системы. Они также используют сеть Интернет для взаимоподключения.
    d) контур лиц, запрашивающих информацию, представляющий собой всех интернет-пользователей, имеющих доступ к публичным разделам Регистра.

    Рис. 1. Архитектура автоматизированной информационной системы

    7) Интернет-пользователь через глобальную сеть Интернет имеет доступ к публичным разделам Регистра о решениях по регистрации, изменению или удалению информации, относящейся к контролерам персональных данных (контролеры), а также к базам данных, информационным или информатическим системам, в которых обрабатываются персональные данные.
    8) Для взаимодействия с Регистром контролер персональных данных подключается через безопасное соединение и выполняет авторизацию, используя имя пользователя + пароль и/или цифровой сертификат, выданный органом по сертификации, признанным в Республике Молдова. После авторизации отправитель заполняет и отправляет обращение о выполнении регистрации, изменении в Регистре /удалении из Регистра. В случае использования цифровой подписи для отправленных документов обращение направляется для обработки сразу после рассмотрения. Если контролер персональных данных не имеет цифровой подписи, выданной органом по сертификации, признанным в Республике Молдова, он получит по электронной почте валидированное системой обращение, которое будет распечатано, подписано, скреплено печатью и представлено лично сотрудникам Центра.
    9) На уровне Центра будут три уровня доступа:
    a) сотрудник Центра;
    b) руководство Центра;
    c) администратор системы.
    10) Для обработки обращений, отправленных контролерами персональных данных, Регистр будет взаимодействовать с целым рядом внешних информатических систем.
    11) Из категории внешних информатических систем можно отметить:
    a) Государственный регистр населения – для проверки IDNP-кодов, содержащихся в заявках о существовании такого лица и допустимость использования такого кода IDNP (лицо не умерло, комбинация фамилия + имя + IDNP совпадают и т.д.);
    b) Государственный регистр правовых единиц – для проверки кодов IDNO или фискальных кодов, содержащихся в формуляре о существовании такого юридического лица и допустимость использования кода (юридическое лицо не исключено и т.д.);
    c) Сервер учреждения по сертификации – внешний сервис по проверке цифровых сертификатов, который может принадлежать Центру специальных телекоммуникаций. Если будут использоваться такие сертификаты, то при первом доступе посредством этого сертификата и его валидации Регистром будет сохраняться список проверенных и принятых публичных сертификатов;
    d) Информационные системы других органов публичной власти – общность информационных систем, которые принадлежат другим органам публичной власти и используются для проверки достоверности данных, представленных контролерами персональных данных.
    12) Из категории внутренних информатических систем можно отметить:
    a) Регистр контролеров персональных данных, который является основной целью настоящей Концепции;
    b) доверенный Сервер – может быть сервер для генерации внутренних цифровых сертификатов либо сервер, который содержит перечень проверенных и подтвержденных публичных сертификатов, выданных внешними организациями.
    13) Учитывая тот факт, что в настоящее время Центр не располагает серверной инфраструктурой, информационное решение может быть изначально размещено в службе M-Cloud, администрируемой Государственным предприятием «Центр специальных телекоммуникаций».
    8. Основные функциональные возможности системы
    1) Общность функциональных возможностей, предоставляемых Регистром и субъектами, которые пользуются ими, приведены на рис. 2. Как показано на рис. 2, информатическая система будет взаимодействовать с девятью группами субъектов:
    a) Интернет-пользователь – общность пользователей лиц, запрашивающих информацию, которые исследуют публичное содержание Регистра посредством поставляемого им веб - интерфейса;
    b) контролер персональных данных - представляет собой общность организаций, которые используют он-лайн функциональные возможности Регистра для отправления обращений по регистрации, изменению данных в Регистре/или их удалению из Регистра;
    c) сотрудник Центра – общность авторизованных пользователей Центра с функциями по рассмотрению обращений, отправленных контролерами персональных данных;
    d) руководство Центра – общность авторизованных пользователей Центра с функциями по принятию решений в отношении обращений, отправленных контролерами персональных данных;
    e) внешний сотрудник – общность авторизованных пользователей других органов публичной власти с функциями по проверке достоверности документов, отправленных контролерами персональных данных;
    f) администратор Регистра – пользователь, обладающий полными правами по администрированию и доступу ко всем функциональным возможностям Регистра;
    g) ГРН – Государственный регистр населения, информатическая система, которая используется для валидации идентификационных данных, относящихся к физическим лицам, содержащихся в обращениях, отправленных контролерами персональных данных;
    h) ГРПЕ – Государственный регистр правовых единиц, информатическая система, которая используется для валидации содержания обращений (идентификационные данные юридических лиц), отправленных контролерами персональных данных;
    i) ИС ОПВ – информатические системы органов публичной власти, которые используются для валидации документов, прилагаемых к обращению контролеров персональных данных.

    Рис. 2. Бизнес функции автоматизированной информационной системы

    2) В соответствии со схемой, описанной на рис.2, актеры Регистра имеют доступ к следующим функциональным возможностям:
    a) UC01. Исследует публичный веб-интерфейс Регистра. Функциональные возможности, общедоступные для всех интернет-пользователей – лиц, запрашивающих информацию, посредством которых они могут формулировать запросы в базе данных для поиска публичной информации или извлечения обезличенной информации;
    b) UC02. Регистрирует профиль в Регистре. Представляет собой функциональную возможность, доступную контролерам персональных данных, используемую во время первой регистрации в системе (необходимой для создания учетной записи и пароля для доступа);
    c) UC03. Заполняет и отправляет обращение. Представляет собой функциональную возможность, доступную контролерам персональных данных, используемую для оформления и отправки обращений о выполнении записи, изменения в Регистре / и их удаления из Регистра;
    d) UC04. Прикрепление копий документов. Представляет собой функциональную возможность, доступную контролерам персональных данных, используемую для прикрепления электронных копий документов, прилагаемых к обращениям о выполнении записи, изменения в Регистре / и их удаления из Регистра;
    e) UC05. Валидация записей. Представляет собой автоматизированную функциональную возможность Регистра, посредством которой компьютер будет автоматически проверять правильность данных, включенных в обращения о выполнении записи, изменения в Регистре/и их удаления из Регистра;
    f) UC06. Получает уведомления. Представляет собой автоматизированную функциональную возможность, доступную контролерам персональных данных, используемую для получения уведомляющих сообщений о принятии/отклонении обращения или получении электронной версии заполненного и валидированного обращения, которое можно будет распечатать, подписать, скрепить печатью и лично представить сотрудникам Центра. Электронная версия обращения будет содержать штрих-код, посредством которого можно будет быстро найти его в Регистре;
    g) UC07. Предоставляет оригиналы документов. Это процедура, посредством которой контролер персональных данных представляет, а сотрудник Центра проверяет подлинность представляемых документов, и принимает оригиналы обращения на бумажном носителе. Сотрудник Центра будет сканировать штрих-код оригинала обращения для быстрого поиска его электронного варианта в Регистре для валидации и начала процедуры его рассмотрения;
    h) UC08. Рассматривает обращения. Представляет собой функциональную возможность, доступную сотруднику Центра для рассмотрения и обработки обращений по регистрации, изменению в Регистре/ и их удалению из Регистра, отправленных держателям контролерами персональных данных;
    i) UC09. Извлекает метаданные, относящиеся к документам. Представляет собой функциональную возможность, доступную для сотрудника Центра для ввода метаданных для документов, отправленных держателям контролерами персональных данных;
    j) UC10. Определяет детали для вынесения решения. Представляет собой функциональную возможность, доступную сотруднику Центра для ввода в Регистр совокупности данных, относящихся к вынесению решения о принятии или отклонении обращения, в соответствии с которым решение будет напечатано;
    k) UC11. Извлекает отчеты. Функциональная возможность, доступная для сотрудников различных уровней Центра, которая позволяет генерировать запланированные или специальные отчеты, а также об информационном содержании информатической системы и деятельности пользователей. Эти отчеты будут полезны для анализа информационной базы системы, эффективности деятельности сотрудников в частности, и Центра в целом, и предупреждении проблем информационной безопасности.
    l) UC12. Решение об обработке обращения. Представляет собой функциональную возможность, доступную на управленческом уровне Центра, используемую для принятия или отклонения обращения, отправленного контролером персональных данных. Информатическая система будет налагать цифровые подписи на решения для последующей передачи их контролеру персональных данных по электронной почте.
    m) UC13. Выдает/публикует решение. Представляет собой функциональную возможность, доступную на управленческом уровне Центра для печати решения на бумаге (с печатью и подписью) или для генерирования файла, который будет скреплен цифровой подписью.
    n) UC14. Регистрирует решение в Регистре. Представляет собой функциональную возможность, доступную на управленческом уровне Центра, для ввода данных из обращения по регистрации/изменению/удалению содержащихся в обращении контролера персональных данных. Процедура полностью автоматизирована и осуществляется системой в соответствии с решением руководителя Центра.
    o) UC15. Рассматривает документы. Представляет собой функциональную возможность, доступную представителю внешнего публичного органа власти, посредством которой он рассматривает информацию о контролере персональных данных и отсканированные документы, прилагаемые к его обращению, отправленному Центру. Сотрудник внешнего публичного органа власти пишет заметки о результатах рассмотрения и подтверждает либо опровергает достоверность документа.
    p) UC16. Автоматически извлекает данные. Регистр в автоматическом режиме извлекает данные из информатических систем других органов власти. Эти данные необходимы для заполнения решения. Автоматическое извлечение данных выполняется на основе, по меньшей мере, одного идентификатора, полученного из информации, относящейся к документам, прилагаемых к обращению. В зависимости от протокола взаимодействия, возможно, потребуется несколько атрибутов, указанных вручную сотрудником Центра. Полученные данные (в том числе отрицательный ответ или сообщение об ошибке соединения) прикрепляются к решению, вынесенному Центром.
    q) UC17. Администрирует пользователей. Представляет собой функциональную возможность, предназначенную для администратора Регистра, посредством которой он администрирует список и целостность полномочий учетных данных сотрудников Центра, в том числе управленческого звена, представителей других органов власти, которые рассматривают и визируют документы, внешних систем, с которыми общение осуществляется с помощью цифрового сертификата.
    r) UC18. Администрирует каталоги и метаданные. Представляет собой функциональную возможность, предназначенную для администратора Регистра, посредством которой он администрирует общность каталогов и метаданных, относящихся к Регистру (включая пользовательский интерфейс информатической системы).
    s) UC19. Другие административные действия. Представляет собой функциональную возможность, предназначенную для администратора Регистра, которая включает все операции по администрированию и обеспечению функциональности Регистра, которые не были описаны в других функциональных возможностях.
    9. Механизм отчетности, аудита и статистики системы
    1) В систему будут внедрены функциональные возможности, предназначенные для аудита/протоколирования, широко используемые в промышленности. Он будет настроен на протоколирование, на большее  или меньшее количество уровней технических и бизнес событий.
    2) Автоматизированная информационная система предоставит возможность автоматически генерировать документы на основе предопределенных шаблонов. Некоторым типам документов, настраиваемым в соответствии со спецификой деятельности, могут быть назначены определенные, заранее предусмотренные форматы. При создании документа подобного типа пользователь должен иметь возможность указать определенную информацию, чтобы далее система автоматически заполнила шаблон в соответствии с  типом документа.
    3) Система отчетности Регистра будет ограничена тремя категориями отчетов:
    a) входящие документы – для каждого типа будет создан свой шаблон, в соответствии с которым будет вставляться информация, соответствующая документам (например: формуляры обращений);
    b) исходящие документы – для каждого типа будет создан свой шаблон, в соответствии с которым  будет вставляться информация, соответствующая документам (например, решения Центра);
    c) отчеты по производительности – представляют собой категорию статистических отчетов (как правило, физически реализованных в содержании информатической системы), направленных на проведение аудита и анализа деятельности информационной системы. К этой категории отчетов можно отнести: трассировку маршрута рабочих процессов; отчет о производительности сотрудника, отчет о производительности подразделения, отчет о производительности сотрудника в целом (число полученных обращений, число обработанных обращений, число обращений с опозданием, показатели производительности и т. д.), отчет критических поручений, который будет выявлять поручения, с превышенным сроком исполнения, с указанием звена, повлекшего блокирование, ответственных лиц и т.д. Для этой категории отчетов целесообразно перенимать принципы аналогичных отчетов, представляемых информатическими системами мониторинга проблем качества (MANTIS, BUGZILLA и т.д.).
    4) Принимая во внимание принцип обеспечения прозрачности деятельности органа публичной власти, информационное решение обеспечит механизм генерирования отчетов посредством  публичного веб-интерфейса Регистра.
    10. Пользовательский интерфейс автоматизированной информационной системы
    1) Регистр должен предоставлять эргономичный интерфейс, интуитивно понятный и доступный для всех типов пользователей. Система должна иметь уникальный графический дизайн, приятный на вид, сбалансированный и четкий. Для удобства пользователей информационное решение будет иметь контекстную помощь он-лайн (версия на государственном языке - обязательно) при использовании для любого уровня веб-интерфейса.
    2) В зависимости от пользователя (его прав и ролей) информатическая система будет предоставлять уникальный интерфейс для каждого пользователя.
    3) Пользователи автоматизированной информационной системы будут обладать шестью уровнями доступа к интерфейсу программы:
    a) уровень доступа Интернет-пользователь – уровень доступа посредством публичного веб-интерфейса, который содержит все функциональные возможности, необходимые для исследования публичного раздела Регистра;
    b) уровень доступа  контролера персональных данных – уровень доступа с авторизованным доступом посредством  имени пользователя + пароль или цифрового сертификата к веб-интерфейсу, характерному контролеру персональных данных, с минимальным набором функциональных возможностей, позволяющих редактирование и отправку обращений по выполнению регистрации, изменению или отзыву либо просмотру всех отправленных обращений, полученных уведомлений и решений, принятых Центром;
    c) уровень доступа сотрудника Центра – уровень, характерный сотрудникам Центра с авторизованным доступом посредством пользователь + пароль и/или цифрового сертификата. Этот тип пользователей будет обрабатывать общность обращений, отправленных контролерами персональных данных;
    d) уровень доступа руководства Центра – уровень, характерный менеджерам Центра, с авторизованныйм доступом посредством пользователь + пароль и/или цифрового сертификата. Этот тип пользователей будет принимать решение об обработке общности обращений, отправленных контролерами персональных данных;
    e) уровень доступа органов публичной власти – уровень, характерный органам публичной власти Республики Молдова, которые будут подтверждать или опровергать достоверность документов, отправленных контролерами персональных данных;
    f) уровень доступа администратора – уровень, характерный пользователю самого высокого уровня. Они будут авторизировать свой доступ посредством цифрового сертификата и физического присутствия при соединении. Этот уровень, учитывая его роль в нормальном администрировании бесперебойной работы информационного решения, обеспечит доступ ко всем функциональным возможностям пользовательского интерфейса и содержанию базы данных, предоставленных пользовательским интерфейсом.
    4) Регистр будет обладать двуязычным интерфейсом – на государственном и русском языках. Обязательной версией по умолчанию является версия на государственном языке. Дополнительно возможна реализация английской версии интерфейса.
    5) Информатическая система должна обладать интегрированными функциями поиска согласно критериям метаданных обращений, решений и уведомлений (поиск обращения, решения, уведомления или всех трех, поиск по календарному периоду, поиск по результату решения и т.д.). Процедуры по поиску информации и записей будут реализованы за счет простого поиска (указание границ поиска) или комплексного поиска более высокого уровня, посредством которых можно выполнять более точную фильтрацию информации (формы Query by Example (QBE) – интерпеляция согласно примеру). Независимо от характера запрашиваемой информации, будет использовать тот же метод запроса и поиска информации для каждого раздела информационного продукта.
    6) В дополнение к поисковому модулю, реализованному на основе принципа QBE, который позволит определить сложные запросы в визуальном виде, интерфейс должен обеспечивать возможность уточнения результатов поиска путем обеспечения возможности фильтрации информации в списках результатов поиска.
    7) Пользовательский интерфейс системы должен обеспечить фильтрацию записей, которые соответствуют критерию поиска, представляемого пользователю в зависимости от  права доступа.
    8) Индексированные значения (значения классификаторов, номенклатур) должны подлежать фильтрации  путем выбора значения по умолчанию из предусмотренных списков. Для полей числового или календарного типа должна быть возможность фильтровать по точному критерию востребованной функции (пример: <01.01.2010 - все записи с указанной датой) или согласно логическим критериям (пример: <01.01.2010 - все записи на дату ранее 01.01.2010 > 01.01.2008 - все записи на более раннюю дату, чем 1 января 2008 года).
    9) Кроме того, должна быть возможность фильтрации по маске результатов (например, фильтрация IDNO) согласно модели: 1006600043* - все последовательности, которые начинаются со строки «1006600043», * ESCU - все последовательности, которые оканчиваются буквами «ESCU», или *ORAR* - все последовательности, которые содержат строку «ORAR».
    10) Должна быть предусмотрена возможность экспортировать содержание любой таблицы c результатами в формате XLS, CSV и PDF.
Раздел IV. Организационная структура системы
    11. Организации, вовлеченные в разработку и функционирование системы
    Следующие учреждения являются заинтересованными или их необходимо вовлекать в разработку и надлежащее функционирование Регистра:
    a) Центр в качестве основного органа, в обязанности которого входят создание и администрирование Регистра, методическая и организационная поддержка для регистрации контролеров персональных данных, мониторинг каждодневной ситуации относительно соблюдения процедур регистрации контролеров персональных данных и т.д.;
    b) контролеры персональных данных в качестве физических или юридических лиц, которые обязаны, согласно закону, регистрироваться в Регистре;
    c) Центр электронного управления в качестве органа, уполномоченного осуществлять деятельность по е-Преобразованию. Центр электронного управления является основным органом, финансирующим проект, и будет принимать активное участие в процессе внедрения и ввода в эксплуатацию информатической системы, включая валидацию и принятие предложений по решению и полученного решения. Центр электронного управления также координирует работу Правительственного портала и решения M-Cloud, которые должны учитываться Регистром;
    d) органы публичной власти (министерства, агентства, службы и др.) в качестве субъектов, выдающих документы, которые контролерам персональных данных необходимо прикреплять к обращениям, направляемым в Центр, достоверность которых должна проверяться;
    e) Министерство информационных технологий и связи в качестве основного органа по политикам и нормам в разработке и внедрении государственных информационных ресурсов;
    f) Государственное предприятие «Центр специальных телекоммуникаций» в качестве субъекта, обеспечивающего содействие и технические средства, необходимые для внедрения и функционирования Регистра. Кроме того, Государственное предприятие «Центр специальных телекоммуникаций» будет являться субъектом, который возьмет на себя информационное решение и будет способствовать внедрению и администрированию информатической системы;
    g) физические и юридические лица в качестве бенефициаров публичного содержания Регистра;
    h) сотрудники органов публичной власти будут использовать систему для выполнения служебных обязанностей и должны быть проинформированы, проконсультированы и обучены для обеспечения навыков работы и ожидаемых результатов.
    12. Держатель системы
    Держателем информационного ресурса является Центр. Роль контролера системы отражает административный и технологический аспект компетенции Центра. Центр несет ответственность за надлежащее функционирование службы и информирование бенефициаров о процессах обработки их формуляров, отправленных в режиме он-лайн.
    13. Администратор системы
    1) Регистр будет располагаться в M-Cloud, а администрирование услугой будет разделено между администратором M-Cloud и Центром. Ответственность администратора M-Cloud будет регулироваться договором SLA (Service Level Agreement).
    2) Администратор системы имеет полный доступ ко всем функциональным возможностям системы, файлам и базам данных, относящимся к системе, в помещения, в которых установлено оборудование и программное обеспечение или которые обеспечивают защиту данных Регистра.
    3) Ответственностью администратора являются:
    a) обеспечение нормального функционирования информатической системы, гарантируя доступность, безопасность и целостность данных;
    b) управление цифровыми сертификатами доступа пользователей (одобрение, отказ и т.д.);
    c) мониторинг активности пользователя в системе;
    d) по письменному требованию  владельца Регистра администратор изменяет функциональные возможности системы (в пределах возможностей, разрешенных для системы) и др.;
    e) техническое администрирование инфраструктуры информатической системы, которое предусматривает:
    администрирование и обеспечение функционирования технического оборудования, на котором работает программное обеспечение, в том числе отвечающее за безопасность периметра сети и доступа к данным;
    предоставление или аренда каналов доступа к широкополосному  доступу в Интернет и государственную сеть;
    администрирование веб-сервера приложений, посредством которого предоставляются услуги, включенные в Регистр.
    14. Пользователи и их роли в системе
    1) Роли лиц или других систем, которые взаимодействуют с Регистром, предоставлены на рис. 3.

    Рис. 3. Роли Регистра

    2) Лицо, запрашивающее информацию – совокупность пользователей, запрашивающих информацию, которые исследуют публичное содержание Регистра посредством предоставляемого им веб-интерфейса. Данный участник имеет следующие отчетливые роли:
    a) имеет доступ к веб-интерфейсу для исследования публичного содержания Регистра;
    b) формулирует запросы на поиск ответа;
    c) имеет доступ к решениям, принятым Центром.
    3) контролер персональных данных – представляет совокупность субъектов, использующих он-лайн преференции Регистра, для отправки обращений по регистрации, изменению или удалению данных в/из Регистра, которые обладают следующими ролями:
    a) редактирует и отправляет обращения по регистрации/изменению/удалению из Регистра и подтверждающие документы, имеющие отношение к обращению;
    b) скачивает решения, относящиеся к контролеру персональных данных.
    4) Сотрудник Центра – участник, представляющий совокупность авторизованных пользователей Центра с функциями по рассмотрению обращений, отправленных контролерами персональных данных, отвечающий за определенные роли:
    a) рассматривает обращения, полученные от контролеров персональных данных;
    b) проверяет достоверность информации, содержащейся в обращении;
    c) заполняет формуляр обращения с метаданными, относящимися к подтверждающим документам, прилагаемым к обращению;
    d) подготавливает проект решения о регистрации/изменении/ удалении данных из Регистра.
    5) Руководство Центра – участник, представляющий общность всех авторизованных пользователей Центра с функциями по принятию решений в отношении обращений, отправляемых контролерами персональных данных. Данный участник обладает следующими ролями:
    a) рассматривает обращения, полученные от контролеров персональных данных;
    b) утверждает/отклоняет проект решения о регистрации/изменении/удалении данных из Регистра;
    c) публикует решение в Регистре;
    d) извлекает соответствующие отчеты по эксплуатации Регистра.
    6) Внешний сотрудник – участник, который представляет общность всех авторизованных пользователей, принадлежащих другим органам публичной власти, с функциями по рассмотрению достоверности документов, отправленных контролерами персональных данных:  
    a) изучает и определяет достоверность подтверждающих документов, представленных контролером персональных данных;
    7) Администратор Регистра – участник, наделенный правом по разграничению пользователей системы, конфигурации Регистра, а также запуска компонентов системы. Если технологическая среда, в которой будет функционировать Регистр, включает возможности, достаточные для удовлетворения административной работы, их реализация в системе является опциональной. Эта категория участников имеет следующие роли:
    a) использует неограниченно все функциональные возможности Регистра;
    b) просматривает любую регистрацию в базе данных;
    c) администрирует сервер приложений;
    d) администрирует производственную базу данных;
    e) администрирует профили пользователей;
    f) администрирует систему каталогов и метаданных;
    g) выполняет резервное копирование базы данных.
    8) Регистр – является автоматизированной информационной системой, которая будет разработана (Регистр контролеров персональных данных).
    9) ГРН – Государственный регистр населения, информатическая система, которая используется для валидации идентификационных данных, относящихся к физическим лицам, содержащихся в обращениях, отправленных контролерами персональных данных;
    10) ГРПЕ – Государственный регистр правовых единиц, информатическая система, которая используется для валидации содержания обращений (идентификационные данные юридических лиц), отправленных контролерами персональных данных;
    11) ИС ОПВ – Информатические системы органов публичной власти, которые используются для валидации документов, прилагаемых к обращению контролеров персональных данных.
Раздел V. Документация системы
    15. Входящая документация системы
    1) Автоматизированная информационная система будет хранить ряд  документов, представляемых контролерами персональных данных и органами публичной власти, для подготовки решения о регистрации, изменении или удалении информации в/из Регистра.
    2) Для реализации истории документооборота Регистр будет формировать электронную папку для каждого обращения от  контролера персональных данных, который  будет содержать как отсканированные копии представленных документов, так и связанные с ними метаданные.
    3) К этой категории документов относятся:
    a) обращения по регистрации;
    b) документы, подтверждающие необходимость регистрации;
    c) обращения по изменению информации;
    d) документы, подтверждающие необходимость выполнения изменений;
    e) обращения по удалению;
    f) документы, подтверждающие необходимость выполнения удаления.
    16. Исходящая документация системы
    1) Автоматизированная информационная система будет генерировать и представлять ряд исходящих документов по решениям Центра о выполнении регистрации или отказе в регистрации, изменении, удалении или о результатах проверок, проведенных у контролеров персональных данных в отношении соблюдения действующего законодательства в области защиты персональных данных.
    2) Для реализации истории документооборота Регистр будет хранить историю взаимодействия с контролером персональных данных, прилагая к его профилю все исходящие документы, которые его касаются.
    3) Из категории исходящих документов можно отметить:
    a) решение о регистрации;
    b) решение об отказе в регистрации;
    c) решение о внесении изменений;
    d) решение об отказе в изменениях;
    e) решение об удалении;
    f) решение об отказе в удалении;
    g) решение по авторизации операций по обработке персональных данных;
    h) решение об отказе в авторизации операций по обработке персональных данных;
    i) решения, связанные с деятельностью Центра, которые касаются контролеров персональных данных  по приостановлению, блокированию обработки данных, предписания и др.;
    j) извлеченные отчеты;
    k) карточка контролера персональных данных с его историей документооборота.
    17. Технологическая документация системы
    К категории технологических документов относятся:
    a) подтверждения со стороны информатических систем органов публичной власти или их сотрудников достоверности предоставленных документов;
    b) записи лог-файлов о взаимодействии пользователей с Регистром;
    c) цифровые сертификаты для пользователей, которые заверяются в  системе.
Раздел VI. Информационное пространство системы
    18. Объекты информационной системы
    Анализируя моделируемую область (обеспечение функциональности Регистра), можно разграничить общность всех информационных объектов, которые должны приниматься во внимание при разработке автоматизированной информационной системы. На рис. 4 разграничены все информационные объекты, которые будут основой для разработки Регистра. Как показано на этом рисунке, речь идет о 5 категориях информационных пунктов, которые должны приниматься во внимание при разработке и внедрении информационной системы: обращение по регистрации, обращение по внесению поправок, обращение по удалению, подтверждающие документы, прилагаемые к обращениям и Решения Центра.

    Рис. 4. Бизнес-функции Автоматизированной информационной системы

    a) Обращение по регистрации
    Является одним из трех типов обращений, отправляемых контролерами персональных данных Центру для их первичной регистрации и создания своего профиля в системе для последующего оформления и отправления он-лайн обращений по выполнению изменений или исправлений в Регистре.
    b) Обращение по изменению
Является одним из трех типов обращений, отправляемых контролерами персональных данных Центру для изменения информации, хранящейся в Регистре в отношении контролеров персональных данных, а также принадлежащих им информационных и информатических систем.
    c) Обращение по удалению
    Является одним из трех типов обращений, отправляемых контролерами персональных данных Центру для удаления из Регистра зарегистрированных данных, в отношении контролеров персональных данных, а также принадлежащих им информационных и информатических систем.
    d) Подтверждающие документы
    Представляют собой отсканированные копии подтверждающих документов, которые контролер персональных данных прилагает к обращениям по регистрации, изменению или удалению.
    e) Решения Центра
    Представляет совокупность всех решений, вынесенных национальным органом по защите персональных данных в результате обработки обращений, направленных контролерами персональных данных, или в результате проверок, проведенных Центром.
    19. Информационные потоки системы
    1) Для обеспечения функциональности Регистра необходимо внедрение 7 категорий информационных потоков, доступных для разных категорий пользователей информатической системы.
    2) Необходимо внедрение следующих информационных потоков:
    a) подготовка и отправка обращения по регистрации. Представляет собой поток, используемый контролером персональных данных для отправки первичного обращения по созданию своего профиля и внесению информации в Регистр;
    b) подготовка и отправка обращения по изменению. Представляет собой поток, используемый контролером персональных данных для отправки обращения по внесению изменений в Регистр. Доступ к этому потоку гарантируется только после авторизации лица, запрашивающего внесение изменений;
    c) подготовка и отправка обращения по удалению. Представляет собой поток, используемый контролером персональных данных для отправки обращения по удалению информации из Регистра. Доступ к этому потоку гарантируется только после авторизации лица, запрашивающего удаление;
    d) утверждение копий документов. Представляет собой поток, используемый эмитентом подтверждающих документов, прилагаемых контролерами персональных данных для проверки их подлинности. В основном будет выполняться автоматизировано, путем сотрудничества с информационными системами соответствующих публичных органов власти или вручную, сотрудниками публичных органов власти;
    e) обработка документов обращения. Представляет собой поток, используемый сотрудниками Центра при обработке обращений, отправляемых контролерами персональных данных. Будет содержать всю бизнес-логику, связанную с подготовкой решения;
    f) подготовка решения. Представляет собой поток, используемый руководством Центра для вынесения решений по обращениям, отправляемыми контролерами персональных данных. Будет содержать всю бизнес-логику, связанную с процессом генерирования решения;
    g) извлечение решения из Регистра. Представляет собой поток, используемый интернет-пользователями в целях извлечения решений, вынесенных Центром в отношении контролеров персональных данных. Представляемые документы будут обезличены и к ним будет автоматически применяться цифровая подпись органа.
    20. Основные сценарии системы
    1) Сценарий по отправке обращений по регистрации
    В соответствии со сценарием, представленным на рис. 5, контролер персональных данных подключается к публичному интерфейсу по подготовке обращения для регистрации своего профиля в Регистре.
    Для этого контролер персональных данных подключается к он-лайн-компоненту Регистра, предназначенному для заполнения и отправки обращения по регистрации, заполняет все обязательные поля формуляра и, по необходимости, дополнительные.
    Информационное решение будет интерактивно проверять точность заполнения формуляра (на основе ограничений, содержащихся в системе метаданных информатической системы или данных, содержащихся в Государственном регистре населения и Государственном регистре правовых единиц).
    Заполненный формуляр может быть скреплен цифровой подписью контролера персональных данных для отправки в Центр.

    Рис. 5. Сценарий по отправке обращений по регистрации

    После получения формуляра система будет отправлять на адрес электронной почты, указанный держателем персональных данных, сообщение о подтверждении правильности адреса электронной почты. После подтверждения, в оптимальные сроки, адреса электронной почты заявителем (гипертекстовые ссылки активации высылаются на адрес электронной почты заявителя) контактный адрес электронной почты валидируется, а обращение по регистрации отправляется для обработки в систему (в случае, когда подтверждение действительности адреса электронной почты не была представлена в определенный срок, обращение контролера персональных данных будет удалено из базы данных).
    Наряду с этим контролеру персональных данных отправляется на контактный адрес электронной почты формуляр обращения по регистрации, прикрепленный PDF-файлом, вложенным в электронное сообщение.
    Для операций по обработке персональных данных, осуществляемых контролерами персональных данных, которые, согласно закону, требуют предварительной проверки (или для которых система будет автоматически запрашивать данную процедуру вследствие значений метаданных, выделенных в обращении по изменению). Регистр будет уведомлять сотрудников Центра об обязательности проведения предварительной проверки обращения по регистрации.
    Сотрудник Центра отправляет на адрес электронной почты контролера персональных данных перечень документов, которые должны быть представлены в Центр.
    Контролер персональных данных распечатает, подпишет, скрепит печатью заполненный формуляр, полученный по электронному адресу, а также подготовит и оформит общность всех подтверждающих документов, запрашиваемых Центром, после чего предоставит их в Центр для валидации регистрации.
    Служащий Центра отсканирует штрих-код обращения (или будет вводить его код) для быстрого его поиска и подтверждения достоверности документов, полученных от контролера персональных данных. Если контролер персональных данных не явится в Центр в течение разумного периода времени для того, чтобы представить запрашиваемые документы для предварительной проверки, лицо, ответственное за осуществление предварительной проверки, внесет соответствующую информацию, использованную ранее в процессе подготовки и принятия решения (о регистрации или отказе в регистрации).
    В результате предварительной проверки служащий Центра подготовит решение об авторизации операций по обработке персональных данных. Положительный результат, содержащийся в этом решении, послужит условием для принятия решения о регистрации обращения контролера персональных данных в процедуре обработки обращения по регистрации.
    После получения решения по авторизации рассмотрения обращения по регистрации следует выполнить все технологические стадии до формирования проекта решения. Проект решения (разрешение на регистрацию или отказ) направляется для окончательного согласования руководству Центра, которое после анализа направляет его на повторное рассмотрение (в случае обнаружения ошибок процедуры или других обстоятельств) или выносит решение.
    В случае положительного решения Система вносит соответствующие записи в Регистр и создает профиль контролера персональных данных, с которым соединит его позже для запроса изменений или удаления (имя пользователя и пароль для доступа к профилю будет взято из электронного формата, изначально заполненного обращения).
    При принятии решения об отказе, профиль не будет создан, но будут внесены соответствующие записи об отказе в регистрации.
    2) Сценарий отправки обращений по изменению
    В соответствии со сценарием, указанным на рис. 6, контролер персональных данных должен авторизироваться в системе для подготовки обращения по регистрации изменений в Регистре.
    Для этого контролер персональных данных подключается к он-лайн-компоненту Регистра, предназначенному для внесения дополнений и отправки обращения по выполнению изменений, заполняя все обязательные поля формуляра и, по необходимости, дополнительные.
    Контролеры персональных данных будут обеспечены удобным интерфейсом для заполнения обращения по запрашиванию изменений  типа ассистент, где они смогут визуально и быстро определить общность всех изменений, которые нужно выполнить. Помимо изменений, контролер персональных данных будет иметь возможность отправлять копии подтверждающих документов для выполнения изменений.
 
    Рис. 6. Сценарий отправки обращений по изменению

    После заполнения формуляр и прилагаемые к нему подтверждающие документы могут быть подписаны цифровой подписью контролера персональных данных для отправки в Центр.
    После получения формуляра система запустит процесс обработки и передачи на контактный адрес электронной почты контролера персональных данных формуляра обращения по запрашиванию изменений, заполненного и прикрепленного в виде PDF-файла к электронному письму.
    Для операций по обработке персональных данных, осуществляемых контролерами персональных данных, которые, согласно закону, требуют предварительной проверки (или для которых система автоматически будет запрашивать эту процедуру вследствие значений метаданных, содержащихся в обращении по изменению), Регистр уведомляет сотрудников Центра об обязательстве по выполнению предварительной проверки обращения по регистрации.
    Сотрудник Центра отправит на электронный адрес контролера персональных данных перечень документов, которые должны быть представлены в Центр.
    Контролер персональных данных распечатает, подпишет, скрепит печатью заполненный формуляр, полученный на электронный адрес, а также подготовит и оформит общность всех подтверждающих документов, запрашиваемых Центром, после чего предоставит их в Центр для валидации обращения по запрашиванию изменений.
    Служащий Центра будет сканировать штрих-код обращения (или будет вводить его код) для быстрого его поиска и подтверждения валидации и точности документов, полученных от контролера персональных данных. Если контролер персональных данных не появится в Центре в течение разумного периода времени для того, чтобы представить документы, запрашиваемые для предварительной валидации, лицо, ответственное за предварительную проверку, внесет соответствующую информацию, использованную ранее в процессе подготовки и принятия решения (о принятии или отказе в регистрации).
    В результате предварительной проверки служащий Центра подготовит решение об авторизации операций по обработке персональных данных. Положительный результат, содержащийся в этом решении, послужит условием принятия решения о регистрации обращения контролера персональных данных по изменению в процедуре обработки обращения по регистрации.
    После получения решения по авторизации рассмотрения обращения по регистрации следует выполнить все технологические стадии до формирования проекта решения. Проект решения (разрешение на изменение или отказ) направляется для окончательного согласования руководству Центра, которое, проанализировав его, направит на доработку (в случае обнаружения процедурных или других ошибок) или вынесет решение.
    В случае положительного решения система вносит соответствующие изменения в Регистр. При принятии решения об отказе будут внесены соответствующие записи об отказе по внесению изменений.
    3) Сценарий отправки обращений по удалению
    В соответствии со сценарием, указанным на рис. 7, контролер персональных данных должен авторизироваться в системе для подготовки обращения по удалению информации из Регистра.
    Для этого контролер персональных данных подключается к он-лайн-компоненту Регистра, предназначенному для внесения дополнений и отправки обращения по выполнению изменений, заполняя все необходимые поля формы и, при необходимости, дополнительные.
    Контролеры персональных данных будут обеспечены удобным интерфейсом для заполнения обращения по запрашиванию удаления, типа ассистент, где они смогут визуально и быстро определить совокупность всех изменений, которые необходимо выполнить. Помимо обращений по удалению контролер персональных данных будет иметь возможность отправлять копии подтверждающих документов для выполнения удалений из Регистра.
    Заполненный формуляр и прилагаемые к нему документы могут быть подписаны цифровой подписью контролера персональных данных для отправки в Центр.
    После получения формуляра система запустит процесс обработки и передачи на контактный адрес электронной почты контролера персональных данных формуляра обращения по запрашиванию удаления,  заполненного и прикрепленного в виде PDF-файла к электронному письму.
 
    Рис.7. Сценарий отправки обращений по удалению

    В отличие от процедуры регистрации и запрашивания изменения, в случае запрашивания удаления обязательно прохождение через механизм проверки обращения по запрашиванию удаления из Регистра.
    Сотрудник Центра отправляет на электронный адрес контролера персональных данных перечень документов, необходимых в процессе предварительного рассмотрения папки по удалению, которые следует представить в Центр.
    Контролер персональных данных распечатывает, подписывает, скрепляет печатью заполненный формуляр, полученный на электронный адрес, а также подготавливает и оформляет подтверждающие документы, запрашиваемые Центром, после чего представляет их в Центр для валидации обращения по запрашиванию изменений.
    Служащий Центра будет сканировать штрих-код обращения (или вводить его код) для быстрого поиска и подтверждения достоверности документов, полученных от контролера персональных данных. Если контролер персональных данных не явится в Центр в разумный период времени для того, чтобы представить запрашиваемые документы в срок для проверки, лицо, ответственное за предварительную проверку, вносит соответствующую информацию, использованную ранее в процессе подготовки и принятия решения (о принятии или отказе в удалении).
    После получения решения по авторизации рассмотрения обращения по регистрации следует выполнить все технологические стадии до формирования проекта решения. Проект решения (удаление или отказ в удалении) направляется для окончательного согласования руководству Центра, которое, проанализировав его, направляет на перерассмотрение (в случае обнаружения процедурных или других ошибок) или вынесет решение.
    В случае положительного решения система выполняет удаление из Регистра. При принятии решения об отказе вносятся соответствующие записи об отказе во внесении изменений.
    4) Сценарий обработки документов обращения
    В случае, если контролер персональных данных отправляет запрос без цифровой подписи, он должен лично явиться в Центр для подтверждения обращения. Сотрудник Центра сканирует обращение и, после обнаружения его в буферной зоне, подтверждает его прохождение в производственную базу данных (если необходимо) для дальнейшей обработки.
    Сотрудник Центра авторизируется для подключения к Регистру в целях обработки поступивших обращений. Сотрудник Центра рассматривает подтверждающие документы и вводит связанные с ними метаданные в Регистр.
    После применения автоматизированных механизмов по проверке целостности обработанных формуляров (проверка IDNP, IDNO и т.д.) с информационными системами других органов публичной власти и проверки подлинности подтверждающих документов обращение получает статус обработанного с отметкой об утверждении или отклонении (по результатам проверки). Работник заполняет все данные, относящиеся к проекту решения.
    Этот компонент позволит вносить проекты решений в отношении контролера персональных данных, созданных в результате деятельности Центра.
    5) Сценарий утверждения копий документов
    Не ставится цель по исчерпывающей проверке подтверждающих документов, отправленных контролерами персональных данных. В случае, когда проверка не может быть выполнена автоматически, она выполняется выборочно.
    Регистр использует два режима для проверки достоверности подтверждающих документов:
    a) автоматически - путем сопоставления метаданных, относящихся к документу с данными, предоставленными из информатических систем органов-эмитентов;
    b) вручную - путем предоставления интерфейса представителю органов публичной власти для изучения копии документа и валидации его либо признания недействительным.
    6) Сценарий оформления решения
    Руководитель Центра (руководство) авторизируется для подключения к Регистру в целях визирования проектов решений по обращениям, полученным для обработки. Руководитель Центра рассматривает правильность содержания полученных обращений, анализирует документы и проекты решения.
    В случае выявления проблем руководитель отмечает проблему и возвращает решение на дополнительную обработку. Если обращение обработано должным образом, он скрепляет решение цифровой подписью, чтобы сделать его действительным.
    После принятия решения вносятся записи в Регистр, а  контролеру персональных данных отправляется по электронной почте уведомление с подписанным файлом решения.
    7) Сценарий извлечения решения из Регистра
    Регистр будет предоставлять ряд возможностей для извлечения решений относительно контролеров персональных данных.
    Они будут доступны посредством публичного интерфейса Регистра. Таким образом, пользователь сможет исследовать содержание Регистра с помощью механизма навигации и системных каталогов и классификаторов или формировать запросы по поиску решений, основываясь на их идентификационных данных. Информация, представленная в публичном интерфейсе, не будет содержать персональные данные, а только общедоступную информацию.
    Контролеры персональных данных смогут получать доступ к решениям из своих профилей в Регистре. Они будут подключаться к своим учетным записям и получать доступ в специальной зоне ко всем касающимся их решениям. Они могут скачиваться в виде файлов, которые скрепляются цифровой подписью Центра, и могут быть использованы в качестве официального документа.
    21. Классификаторы и номенклатура системы
    1) В целях обеспечения точности и сокращения объема информации, хранящейся в Регистре, будут использоваться классификаторы и номенклатуры, которые можно разделить на три группы:
    a) международные;
    b) национальные (CUATM, CAEM, FOJ, CFP и др.);
    c) внутренние (интерфейс, пользователи, группы пользователей, категории документов, категории решений и т.д.).
    2) Внутренние классификаторы и номенклатуры будут разработаны и будут использоваться в Регистре только в случае отсутствия утвержденных национальных и международных классификаторов.
    22. Взаимодействие с другими информатическими системами
    Для обеспечения функциональности в оптимальных условиях Регистра необходима реализация взаимодействия с четырьмя категориями информатических систем:
    1) Взаимодействие с информатическими системами ГП «Центр специальных телекоммуникаций»
    Это взаимодействие используется для реализации механизмов цифровой подписи, которая предоставляет собой возможность проверки личности пользователя, определяет, имеет ли пользователь право представлять документы, обеспечивает защиту отправленной информации, которая не может быть изменена после подписания документов. Все это будет достигнуто за счет использования следующих услуг, предоставляемых Центром специальных телекоммуникаций:
    a) проверка сертификата;
    b) проверка подписи;
    c) обращение и прием знака времени.
    Функции знака времени используются на этапе отправки документов. Знаки времени получаются системой от приложения-клиента, подключенного к государственному сервису Time-Stamping.
    Таким же образом осуществляется взаимодействие с Правительственным порталом, администрируемым Центром специальных телекоммуникаций, для обеспечения доступа к ресурсам Регистра посредством Портала.
    2) Взаимодействие с Государственным регистром населения
    Это взаимодействие будет использоваться для подтверждения записей обращений по выполнению регистрации, изменению или удалению (содержащих сведения о физических лицах) в целях подтверждения правильности комбинаций IDNP, имя, фамилия, удостоверение личности.
    3) Взаимодействие с Государственным регистром правовых единиц
    Это взаимодействие будет использоваться для подтверждения записей обращений по выполнению регистрации, изменению или удалению (содержащих сведений о юридических лицах) в целях подтверждения  правильности комбинаций IDNО, название, код CAEM и т.д.
    4) Взаимодействие с информатическими системами других органов публичной власти
    Это взаимодействие будет использоваться для проверки достоверности документов, представляемых контролерами персональных данных в соответствии с информацией, хранящейся в информационных системах органов публичной власти.
Раздел VII. Технологическое пространство системы
    1) Регистр состоит из одного или нескольких серверов, предназначенных для службы (рис.8). На серверах в первую очередь размещается Регистр, который реализует бизнес-логику информатической системы и взаимодействия с другими подсистемами.
    2) Регистр публикует несколько интерфейсов, и для них реализуется  по одному внедрению, а именно:
    a) веб-служба подачи обращений, которая взаимодействует с внешним миром и первоначально будет доступна непосредственно через веб-страницу Центра (http://www.datepersonale.md). Впоследствии планируется интеграция этой службы и  в Правительственный портал;
    b) веб-служба извлечения отчетов, которая взаимодействует с внешним миром и первоначально будет доступна непосредственно через веб-страницу Центра (http://www.datepersonale.md). Впоследствии планируется интеграция этой службы и  в Правительственный портал;
    c) веб-служба рассмотрения обращений, которая позволит сотрудникам Центра и внешним представителям рассматривать полностью или частично обращение, поданное запрашивающими лицами;
    d) веб-служба подготовки решения, представляющая собой средство, которое позволит Центру проверять правильность полученных документов и заполнять набор метаданных, необходимых для вынесения решения;
    e) веб-служба разработки решения, которая позволит Центру рассматривать относящиеся к ним обращения и документы, проекты решений для их принятия или возвращения на дополнительную обработку в случае обнаружения проблем;
    f) веб-служба извлечения решений, которая позволит интернет-пользователям, запрашивающим информацию возможность нахождения, просмотра и сохранения решений, вынесенных Центром.

     Рис. 8. Компоненты автоматизированной информационной системы

Раздел VIII. Обеспечение информационной
безопасности системы
    1) Под информационной безопасностью понимается защита информационных ресурсов и инфраструктуры от случайных или умышленных действий естественного или искусственного характера, целью которых является причинение ущерба участникам процесса информационного обмена.
    2) Обеспечение безопасности будет включать совокупность законодательных, организационных, экономических и технологических мер, направленных на предотвращение угроз безопасности ресурсов и информационной инфраструктуры.
    3) Можно выделить следующие проблемы в обеспечении информационной безопасности, с которыми будет сталкиваться Регистр:
    a) обеспечение конфиденциальности информации (предотвращение получения информации людьми, которые не имеют таких прав и полномочий);
    b) обеспечение логической целостности данных (предотвращение неавторизованного ввода, обновления и удаления информации или ввода искаженных данных);
    c) обеспечение безопасности информационной инфраструктуры от попыток повреждения или изменения ее функционирования.
    4) Основными используемыми механизмами информационной безопасности будут:
    a) аутентификация и авторизация информации;
    b) администрирование доступа к информации;
    c) регистрирование действий пользователей системы;
    d) шифрование информации;
    e) информационный аудит;
    f) процедуры аварийного восстановления.
    5) Одним из наиболее уязвимых звеньев в системе информационной безопасности является человеческий фактор. С этой точки зрения обучение сотрудников методике устойчивости к информационным угрозам является очень важным элементом.
    6) В процессе разработки Регистра для обеспечения информационной безопасности будут учитываться алгоритмы и протоколы, существующие на рынке, с соблюдением правовой базы Республики Молдова, в том числе:
    a) Закон № 982-XIV от 11 мая 2000 года о доступе к информации;
    b) Закон №. 467-XV от 21 ноября 2003 года об информатизации и государственных информационных ресурсах;
    c) Закон №. 264-XV от 15 июля 2004 года об электронном документе и цифровой подписи;
    d) Приказ Службы информации и безопасности № 64 от 7 декабря 2006 года об утверждении Технических норм в сфере цифровой подписи;
    e) Постановление Правительства № 320 от 28 марта 2006 года «Об утверждении Положения о порядке применения цифровой подписи в электронных документах органов публичной власти».
    7) Дополнительно будут запланированы организационные, технологические и программные меры в соответствии с международными стандартами, принятыми как национальные в Республике Молдова: SM GOST R ISO/CEI 15408:2009, SM ISO/CEI 17799:2004 и SMV ISO/CEI 27002:2009.
    8) Исходя из вышеизложенного, доступ к ресурсам Регистра должен быть обеспечен и авторизирован посредством системы пользователей и паролей и/или авторизироваться через цифровой сертификат. Тем не менее, пользователи будут обладать разными правами доступа, в зависимости от уровня безопасности, которому они соответствуют. Для каждой группы доступа должна быть возможность определения ролей и прав пользователей (даже до уровня доступа к пользовательскому интерфейсу).
    9) Доступ к информации базы данных должен быть ограничен в зависимости от прав и ролей, специфичных для каждой группы доступа. В этом случае каждая группа пользователей будет иметь доступ к персонализированному интерфейсу (отличающемуся от интерфейсов других групп) для просмотра и управления информацией базы данных, а также манипулирования данными.
    10) Независимо от уровня доступа пользователя (администратор или сотрудник центра) ни одна группа доступа не должна обладать правом непосредственно уничтожать записи базы данных. Физическое уничтожение должно сопровождаться маркировкой об удалении. Только после маркировки эти записи будут физически удалены пользователями с правами администратора.
    11) Любое потенциально опасное изменение: изменение информации записи, маркировка об удалении, добавление новых записей и т.д. – должно быть задокументировано в специальных электронных регистрах (лог-файлах) с указанием момента времени и пользователя, который внес потенциально опасное изменение. В случае, если потенциально опасные изменения не связаны с физическим  уничтожением данных для каждой записи, можно будет увидеть, какой пользователь выполнил последнее изменение. Таким образом, проектируемая информатическая система будет обладать эффективным инструментом, который позволяет выполнять анализ поведения пользователей (или их производительность).
    12) На физическом уровне политика по обеспечению информационной безопасности должна быть реализована посредством автоматических модулей генерирования резервных копий файлов и баз данных, находящихся в производстве. Администраторы Регистра должны иметь возможность определять политику автоматического  генерирования резервных копий.
    13) В целях обеспечения надлежащего уровня информационной безопасности Регистра приветствуется разработка и внедрение политики обеспечения информационной безопасности. Эта политика будет объединять совокупность компонентов безопасности, роли, права и обязанности каждого участника системы. Для развития политики обеспечения информационной безопасности желательно контрактировать услуги иностранных экспертов или сертифицированных в этой области компаний.
    14) Политика безопасности будет доведена до сведения каждого пользователя и подписана им. Каждый пользователь должен знать служебные обязанности в части соблюдения информационной безопасности и все формальные процедуры, которые должен соблюдать в строгом соответствии с политикой безопасности.
    15) Для обеспечения подлинности информации будет создана политика, которая будет определять механизмы валидации информации, вводимой в систему или извлекаемой из нее.
    16) Центр будет иметь квалифицированный персонал по выполнению аудита информационной безопасности, проверки и, непрерывно обучающийся в области обеспечения информационной безопасности.
Раздел IX. Внедрение системы
    Действия по проектированию, реализации, тестированию и внедрению всех компонентов Регистра должны реализовываться специализированными организациями и учреждениями, обладающими лицензиями, необходимыми для выполнения соответствующих работ, и включающими в себя следующие этапы:
    a) этап  разработки автоматизированной информационной системы – будет разделен на фазы, согласованные со сторонами (Центр электронного управления, Национальный центр по защите персональных данных, Центр специальных телекоммуникаций), вовлеченными в процесс  разработки Регистра;
    Разработчик: 
    на основании технического задания определяет и анализирует требования, проектирует структуру системы и создает технический проект;
    разработает код приложения и интегрирует его модули, разработанных в первой версии программного обеспечения системы (проводит первую  презентацию сторонам, демонстрируя наличие всех функциональных возможностей, представленных в техническом задании);
    проводит тестирование системы в лабораторных условиях (внутреннее тестирование) и подготавливает сопроводительную документацию (представляет функциональные возможности системы с исправлениями и уточнениями, сделанными в предыдущем субэтапе, представляет набор технической документации и т.д.);
    b) этап внедрения системы начнется с момента утверждения протокола о принятии владельца системы программного обеспечения в представленном варианте и подписании акта приема-передачи в экспериментальное пользование. На данном этапе разработчик тестирует систему в экспериментальных условиях, обнаруживает и устраняет ошибки, проблемы, связанные  с производительностью и т.д. На этом этапе разработчик готовит окончательный вариант системы, который может быть введен в эксплуатацию;
    с) этап обучения начнется с момента внедрения информационного решения и будет включать в себя подготовку 2 системных администраторов, 20 пользователей Центра с различными уровнями доступа;
    d) этап сдачи в эксплуатацию системы начинается с момента подписания акта ввода в эксплуатацию и начала использования программного обеспечения системы;
    e) этап технического обслуживания системы, в течение которого разработчик системы берет на себя обязательство оказывать владельцу помощь в техническом обслуживании мощностей программного обеспечения системы, по предоставлению услуг и изменения программного обеспечения, сохранения его целостности. Этот этап может быть любой продолжительности в зависимости от контрактных соглашений.