Стандарты и архитектуры для приложений е

SAGA
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Стандарты и архитектуры для приложений е-правительства
Версия 2.0
Введение ................................................................................................................................4
1.1. Предпосылки ..................................................................................................................4
1.2. Читатели данного документа........................................................................................5
1.3. Цели и структура документа ........................................................................................5
1.3.1.
Основные принципы .............................................................................................5
1.3.2.
Цели ........................................................................................................................6
1.3.3.
Задачи .....................................................................................................................6
1.3.4.
Рамки.......................................................................................................................7
1.3.5.
Структура данного документа ..............................................................................7
1.4. Охваченные услуги........................................................................................................8
1.5. Взаимодействие с другими документами е-правительства .......................................9
1.6. Процесс развития .........................................................................................................11
2. Эффект и согласованность приложений ......................................................................12
2.1. Обоснованность и эффект от SAGA ..........................................................................12
2.2. Классификация и жизненные циклы стандартов .....................................................12
2.3. Соответствие стандартам SAGA ................................................................................12
2.3.1.
Определение соответствия .................................................................................12
2.3.2.
Декларация соответствия ....................................................................................13
2.3.3.
Соответствие в случае стандартов с другой классификацией ........................14
2.3.4.
Ответственность за соответствие .......................................................................14
2.3.5.
Перенос соответствия .........................................................................................14
2.3.6.
Несоответствие ....................................................................................................15
3. Архитектурная модель для приложений е-правительства .......................................15
3.1. Общие сведения ...........................................................................................................15
3.2. Аспект предприятия ....................................................................................................17
3.3. Информационный аспект ............................................................................................18
3.4. Вычислительный аспект .............................................................................................18
3.5. Инженерный аспект.....................................................................................................20
3.6. Технологический аспект .............................................................................................20
4. Аспект предприятия: основы е-правительства...........................................................20
4.1. Рамки компетенции для е-правительства в Германии .............................................21
4.1.1.
Дефиниция е-правительства ...............................................................................21
4.1.2.
Дефиниция термина «услуга» ............................................................................21
4.1.3.
Философия, лежащая в основе е-правительства ..............................................21
4.1.4.
Организационные требования ............................................................................23
4.1.5.
Правовые рамки полномочий .............................................................................25
4.1.5.2.
Распространение электронной подписи ................................................................26
4.2. Рамки полномочий для приложений е-правительства .............................................28
4.2.1.
Взаимодействие в е-правительстве ...................................................................28
4.2.2.
Транзакции в е-правительстве............................................................................29
4.2.3.
Модули осуществления электронных процедур ..............................................31
5. Информационный аспект: хранилище схем ................................................................32
6. Вычислительный аспект: эталонная архитектура программных средств............33
6.1. Требования и предварительные условия ...................................................................34
6.1.1.
Предварительные условия и рамки эталона для конкретных администраций
34
6.1.2.
Взаимодействие и возможность повторного использования ..........................35
6.1.3.
Дальнейшие основные требования к архитектуре программного обеспечения
36
1.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
6.2. Архитектурные решения.............................................................................................38
6.3. Эталонная архитектура для приложений е-правительства......................................41
6.3.1.
Основные функциональные возможности используемых компонентов .......41
6.3.2.
Структура типового специального приложения ..............................................43
6.4.
Выводы из архитектуры программного обеспечения ..............................................44
7. Инженерный аспект: эталонная архитектура .............................................................44
7.1. Проектирование инфраструктуры е-правительства .................................................45
7.1.1.
Физическая инфраструктура ..............................................................................45
7.1.2.
Зональная концепция и коммуникационные отношения ................................46
7.1.3.
Сетевой доступ и контроль доступа ..................................................................47
7.2. Сеть, пользователи и внешние сервисы ....................................................................48
8. Технологическая точка зрения (часть 1): стандарты ИТ архитектуры .................49
8.1. Моделирование процесса............................................................................................49
8.2. Моделирование данных ..............................................................................................49
8.2.1.
Инструменты моделирования ............................................................................49
8.2.2.
Описание данных.................................................................................................50
8.2.3.
Трансформация данных ......................................................................................50
8.2.4.
Характерные множества .....................................................................................50
8.3. Архитектура приложения ...........................................................................................50
8.3.1.
Архитектура приложения с промежуточным ПО ............................................50
8.3.2.
Архитектура приложения без применения промежуточного ПО
промежуточного ПО ............................................................................................................52
8.4. Клиент ...........................................................................................................................52
8.4.1.
Основанный на web/основанный на компьютерах доступ к информации ....53
8.4.2.
Доступ к информации через мобильные телефоны / PDA ..............................54
8.4.3.
Доступ к информации через внешние системы ................................................54
8.5. Презентация .................................................................................................................55
8.5.1.
Обработка информации – компьютер/ web .......................................................55
8.5.2.
Обработка информации – мобильный телефон/ PDA ......................................62
8.5.3.
Обработка информации – внешние системы ....................................................63
8.6. Коммуникации .............................................................................................................63
8.6.1.
Протоколы промежуточного ПО .......................................................................63
8.6.2.
Сетевые протоколы .............................................................................................64
8.6.3.
Протоколы приложения ......................................................................................65
8.6.4.
Предписывающие услуги ...................................................................................66
8.7. Соединение с задней частью ......................................................................................66
8.7.1.
Диалоговые системы ...........................................................................................67
8.7.2.
Групповая обработка ...........................................................................................67
8.7.3.
Связь Программа к программе ...........................................................................67
9. Технологический аспект (часть II): стандарты безопасности данных ...................68
9.1. Цели и принципы безопасности данных ...................................................................68
9.1.1.
Цели защиты ........................................................................................................68
9.1.2.
Требования защиты .............................................................................................69
9.1.3.
Структурная модель безопасности данных ......................................................69
9.2. Стандарты для концепции безопасности ..................................................................70
9.3. Стандарты для конкретных приложений ..................................................................71
9.3.1.
Безопасная передача веб-содержания и аутентичность веб-сервера .............71
9.3.2.
Защита email-коммуникаций ..............................................................................72
9.3.3.
Защищенный обмен документами .....................................................................74
9.3.4.
Транзакции ...........................................................................................................76
9.3.5.
Веб-сервисы .........................................................................................................76
9.4. Общие стандарты безопасности данных ...................................................................77
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
9.4.1.
9.4.2.
9.4.3.
9.4.4.
9.4.5.
9.4.6.
Аутентификация ..................................................................................................77
Интеграция инфраструктуры безопасности ......................................................78
Интеграция смарткарт .........................................................................................78
Управление ключами ..........................................................................................78
Криптографические алгоритмы для электронной подписи.............................79
Симметричные криптографические алгоритмы для шифрования .................80
Приложение А Основные модели инициатив BundOnline
A.1 Основной компонент - Платежная платформа («е-payment»)
A.2 Основной компонент – Безопасность данных («virtual post office»)
A.3 Основной компонент – Портал
А.4 Основной компонент - Сервер форм
А.5 Основной компонент – система управления контентом
А.6 Компонент инфраструктуры – Информационная Сеть
Федеральной
администрации
А.7 Сервис директорий как компонент инфраструктуры
А.8 Услуга «Одна для всех»
А.9 Центры компетенции
Приложение В Примеры интерактивных услуг с основными компонентами
Приложение С Образцы для объявления согласованности SAGA
С.1 Объявление Согласованности
С.2 Контрольный список для саморазвивающихся компонентов
С.3 Контрольный список для компонентов, являющихся результатом
Приложение Д Ссылки
Приложение Е Обзор конфиденциальных стандартов???
Приложение Ф Аббревиатура
Введение
В этом документе в вкратце представлены стандарты, процессы, методы и
продукты, полученные в процессе разработки приложений е-правительства. Эксперты,
работающие в данном секторе, используют много сокращений и, в большинстве случаев
английских, акронимов. Некоторые из этих имен защищены авторскими правами или/и
зарегистрированы как торговые марки и продукты известных производителей либо
организаций по стандартизации на национальном и международном уровнях.
1.
1.1.
Введение
Предпосылки
Разработкой Стандартов и архитектур для приложений е-правительства (САПП)
(SAGA), федеральное правительство делает важный вклад в процесс построения
современного и сервис - ориентированного управления.
В сентябре 2000 года, Канцлер Герхард Шредер запустил первый шаг еправительства - BundOnline 2005, средствами которого федеральное правительства
обещало к 2005 году реализовать 400 интерактивных Интернет - услуг. Гражданам и
деловому сообществу должен быть предоставлен приветливый доступ к услугам
административного Интернета. Для надлежащего контроля и координации инициатив еправительства в Министерстве внутренних дел создана проектная группа.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Проектная группа набросала план реализации и обновила его в годовом отчете
разработанного для федерального кабинета. Кроме децентрализованного пакета услуг,
предназначенных к реализации разными общественными агентствами, основные
компоненты и приложения определенные планом реализации развиты согласно принципу
«один для всех». В будущем, все приложения е-правительства смогут гладко
взаимодействовать друг с другом. Это вызывает необходимость в способности к
взаимодействию компонентов
BundOnline 2005 на основе общей архитектуры и
стандартов.
Данные стандарты были сформулированы Координационным и консультативным
агентством Федерального Правительства по информационным технологиям в
Федеральной администрации. Агентство при участии экспертов с производства и других
специалистов из федеральных, федерально-земельных и муниципальных администраций
идентифицировало и оценило существующие стандарты. Инвентаризация и оценка
создала основу для первой версии Стандартов и Архитектур. Для приложений еправительства. Авторы САПП на данный момент имеют документ, обновленный во
взаимодействии с проектной группой BundOnline 2005 и экспертной группой.
1.2.
Читатели данного документа
САПП первоначально разрабатывался для лиц, принимающих решения в области
организации и информационных технологий (команды е-правительства) германских
администраций. Документ является директивой, служащим для ориентировки, в случаях,
когда он применяется к развитию концепций для технических архитектур и общих
технических концепций для индивидуальных ИТ - приложений.
Разработчики приложений не должны испытывать ограничений в поиске
детальных решений в случае, когда данные стандарты не обеспечивают возможность
реализации технических требований.
Реализуя свои инициативы, федеральное правительство вносит огромный вклад в
развитие е-правительства Германии. Опыт, рассмотренный в данном документе, и
основные компоненты, реализованные в рамках проекта BundOnline 2005, предназначены
для помощи пользователям в построении карьеры с помощью социальных агентств и для
успешного осуществления инициатив национального е-правительства.
1.3. Цели и структура документа
1.3.1. Основные принципы
Современному е-правительству необходимы идеально взаимодействующие
информационные и коммуникационные системы. Простые и четко сформулированные
стандарты и спецификации помогут достигнуть такого взаимодействия систем. САПП
идентифицирует необходимые стандарты, форматы и спецификации, они составлены из
ратифицирующих правил и обновляют их согласно требованиям времени.
Приложения е-правительства развиваются согласно следующим принципам:
a)
Приложения е-правительства первоначально используют браузер как
внешний интерфейс, если услуги, которые будут реализованы, могут оказываться через
браузер.
b)
Они работают без активного содержания для избежания необходимости
снижения уровня безопасности сервера, т.о. не нанося вред ненадежностью сайтов, либо,
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
используются исключительно подписанные и приложения защищенного качества, типа
рассмотренного в секции 8.5. на странице 76.
c)
Приложения е-правительства не содержат какие-либо части программы или
данные на пользовательских компьютерах, которые не могут быть проконтролированы
пользователем.
1.3.2. Цели
САПП преследует следующие цели:
a)
Гарантировать потоки информации, действующие между гражданами,
федеральным правительством и его партнерами (способность к взаимодействию).
b)
Запустить процедуры для обеспечения услуг и для формулирования моделей
данных; федерально-земельные правительства и коммунальные администрации имеют
возможность использовать результаты полученные от внедрения инициатив BundOnline
2005.
c)
Обеспечить технические требования в форме общественно доступной
документации (открытость)
d)
Рассматривать события на рынке и в сфере стандартизации (снижение цен и
рисков)
e)
Гарантировать применимость решений к устранению причин проиходящих
изменений в требованиях к объему и частоте транзакций (масштабируемость).
1.3.3. Задачи
САПП полномасштабное стандартизированное руководство к построению
инициатив BundOnline 2005, которое в процессе своего развития фокусируется на четырех
направлениях:
a)
архитектур;
b)
c)
d)
Формулирование
технических
нормативных
ссылок,
стандартов
и
Моделирование процесса;
Моделирование данных;
Развитие компонентов.
Формулирование технических нормативных ссылок, стандартов и архитектур
Технические стандарты и архитектуры охватывают все наиболее значимые уровни
и компоненты е-правительства (см. главу 3). Они являются основой для обеспечения
взаимодействия и совместимости в процессе разработки приложений е-правительства и
основных компонентов инициативы BundOnline 2005.
Моделирование процесса
Разработать модель процесса, значит, создать методическое описание процессов еправительства в целом, либо частично (см. секция 3.2., стр. 31), для того, чтобы:
a)
Достичь похожего и сопоставимого дизайна и макета различных
приложений.
b)
Гарантировать высокий уровень возможности повторного использования
процессов и систем.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Моделирование данных
Разработать модель данных, значит, создать методологически стандартизированное
описание данных собранных в рамках процессов е-правительства в целом, либо частично
(см. секцию 3.3., стр. 32), для того, чтобы:
a)
Гарантировать возможность взаимодействия различных – в том числе
будущих – приложений;
b)
Гарантировать высокий уровень возможности повторного использования
процессов и систем.
Развитие компонентов
Основные компоненты подобраны, специфицированы и реализованы BundOnline
2005 на основе часто используемых, общих моделей процесса. Пять основных
компонентов и два компонента инфраструктуры вошли в фазу имплементации (см.
Приложение А, стр. 108).
1.3.4. Рамки
САПП является проектом стандартизации с интегрированным подходом, который
описывает все необходимые аспекты для достижения вышеупомянутых целей. Стандарты
или архитектуры не упомянутые ниже:
a)
приложения, не относящиеся к е-правительству или е-коммерции;
b)
ссылка на иной детальный уровень, нежели те стандарты, что связаны со
стандартами из САПП;
c)
включенные либо те, на которые были ссылки в вышеупомянутых
стандартах;
d)
очень новые, либо вызывающие сомнения и те, которые в будущем с малой
вероятностью станут стандартами;
e)
нежелательные, т.е. такие стандарты, которые конфликтуют с
вышеописанными стандартами и архитектурами, либо ограничивают взаимодействие.
Более того, САПП принимает только те области, которые и имеют большее
влияние на вышеупомянутые цели, чем все элементы технической архитектуры.
1.3.5. Структура данного документа
После Введения, глава 2 обращается к ценным бумагам, относящимся к связующей
сущности САПП и к адекватности САПП приложений САПП. Глава 3 описывает
архитектуру модели для приложений е-правительства. Эта модель была адаптирована к
описанию e-government подходу Германии. Т.о., следующие главы 4-9 представляют
аспект е-правительства как единого целого.
Глава 4 «Аспект предприятия: основы е-правительства» документирует цели
германского е-правительства, актеров, ролей, сфер деятельности, директив форм
взаимодействия. Глава 5 «Информационный аспект: хранилище схем» связана с работой
по развитию унифицированных и стандартизированных моделей данных. Глава 6
представляет справочную информацию по архитектуре программных продуктов как
основы для развивающихся архитектур для конкретного приложения е-правительства
(Вычислительный аспект). Глава 7 «Технический аспект: эталонная архитектура» адресует
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
требования для компьютерных центров е-правительства и интеграция основных модулей в
существующую инфраструктуру (технический аспект). Глава 8 и 9 определяют стандарты
САПП для ИТ – архитектуры для обеспечения информационной безопасности и полноты
(технологический аспект).
Приложение А. предлагает детальное описание основных модулей инициативы
BundOnline 2005. Также представлены: выполняемые функции, классифицированные
деловые ситуации (сценарии приложения), сетевые графики, интерфейсы основных
компонентов и компоненты инфраструктуры. И более того, были представлены услуги
типа - «один для всех», являющиеся наиболее важными, вместе с информацией о центрах
компетенции, которые оказывают поддержку в развитие приложений е-правительства. 0
представляет пример интерактивной услуги, используемой множеством основных
компонентов. Приложение В. содержит шаблон для приготовления САПП согласовательной декларации. Приложение С. содержит ссылки, Приложение Д. содержит
алфавитный список стандартов используемых в главах 8 и 9. Приложение Е. в заключение
представляет список аббревиатур используемых в САПП.
1.4.
Охваченные услуги
Документ определяет три целевые группы для федеральных административных
услуг (см. подборку представленную на рис. 1-1).
a)
Правительство – Граждане (G2C): услуги, которые федеральное
правительство предлагает гражданам
b)
Правительство – Бизнес (G2B): услуги, которые федеральное правительство
предлагает бизнес структурам
c)
Правительство - Правительство (G2G): услуги, которые федеральное
правительство предлагает общественным организациям
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
G2C
Правительство Граждане
Смена работы
Платежи
Расчеты и пенсионные
платежи
Предоставление
информации
Консультации
Прогноз погоды и
метеорологические
сообщения
Схема пенсионных
накоплений
Предоставление
специальной и
технической информации
Предоставление
информации и других
руководств
Продвижение
обновляемой энергии
G2B
Правительство Бизнес
Смени работы
Закупки
Закупки для
конструкторских и
общественных
прикладных проектов
Таможенная очистка,
экспорт и импорт
Центральная статистика
Проектные субсидии
Информация по
проблеме сил,
регулирующих
деятельность банков
Оценка VAT чисел
Процедуры присуждения
соответствующей VOLJA,
VOBJA, VOF
Кодировка телефонного
номера
G2G
Прав-во – Правво
Управление
регистрацией
общественного
транспорта и
мототранспорта
Закупки кассир
Центральный офис
федерального
правительства
Закупки для
конструкторских и
общественных
Управление имуществом
федерального
правительства
Продолжение обучения и
образование
Центральная статистика
Центральный
федеральный офис
регистрации
преступлений
Рис. 1-1 Набор услуг федерального правительства
Определено приблизительно 400 услуг различных федеральных администраций.
Анализ услуг по критерию значимости позволил определить 8 типов услуг. 73 процента
услуг, используемых в данный момент, принадлежит трем типам:
a)
b)
c)
Сбор, обработка и предоставление информации
Обработка приложений и запросов, отравляемых в административный офис
Обработка субсидий и вспомогательные приложения
1.5.
Взаимодействие с другими документами е-правительства
Стандарты и архитектуры для е-правительства Германии, как и других стран,
находились на стадии разработки несколько лет. Опыт этих испытаний и международный
обмен сделал вклад в продвижение формирования и применения САПП.
САПП был опубликован как часть серии публикаций KBSt, который также
включил, например, “V-Modell”, “Migration Guide” и “DOMEA”. Документы этой серии
процессе корректировки были приведены к общему виду. Это значит, что САПП заменяет
утверждения и информацию документов созданных ранее, а также новые докуманты
согласуются с утверждениями и информацией последней версии САПП. Открытый
координационный процесс сопровождается любым из обновлений САПП для избежиния
конфликтов с действующими документами.
Руководство по Е-правительству
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Для продвижения инициативы BundOnline 2005 и поддержки федеральноземельной и муниципальной власти, руководство по е-правительству подготовлено под
руководством Германского Федерального Офиса по Информационной безопасности (BSI).
Данное руководство разрабатывалось как справочное руководство и центральное средство
для обмена информацией о вопросах, относящихся к е-правительству.
Руководство по е-правительству – это модульное собрание материала, которое
охватывает более широкий круг вопрос и тем, чем САПП. Что касается подобных
вопросов, руководство е-правительства рассматривает их более конкретно. Поэтому на
некоторые модули руководства по е-правительству определены ссылки из САПП. САПП
излагает руководящие принципы, а руководство по е-правительству раскрывает
применение этих принципов и дает практические советы.
В середине февраля 2003 года САПП становится частью руководства по еправительству. Он является модулем руководства с самым сильным обязывающим
действием. Все остальные модули разрабатывались для того, чтобы гарантировать
согласованность с САПП.
Руководство по защите ИТ-базиса
Руководство по приготовлению Концепций по ИТ-безопасности для нормальных
требований безопасности (Руководство по защите ИТ-базиса) рекомендует стандартные
мероприятия для типовых ИТ систем. Целью данных требований по защите ИТ-базиса
является достижение безопасного уровня для ИТ систем через подходящие приложения
стандартных мероприятий по безопасности на организационном, кадровом,
инфраструктурном и техническом уровнях, которые в данный момент являются
приемлемыми и подходящими для нормальных требований защиты и которые могут
служить основой для ИТ систем и приложением с высоким уровнем требовании к защите.
САПП требует приложения руководства по защите ИТ-базиса так как он определен
как обязательный стандарт.
Предписание по информационным технологиям свободным от барьеров
На предписание по созданию информационной технологии свободной от барьеров
согласованной с 11 статьей закона о равенстве прав граждан, лишенных дееспособности,
который был принят 24 июня 2002 года, есть ссылки в САПП и определен как
обязательный стандарт к реализации презентации и клиентского уровня.
V-modell
Процедурный модуль «V-modell»- это стандарт развития для ИТ систем
федеральных агентств с обязательным действием для полной площади федеральной
администрации. Он состоит из определенных центральных элементов, т.е. «процедурный
модуль», «метод выделения (allocation method)» и «требования к функциональным
инструментам», и описывает деятельность и результаты, полученные и генерируемые в
процессе разработки программных продуктов.
Эта модель должна быть принята во внимание в стратегическом планировании, в
процессе управления проектом, а также в связи с внедрением приложений е-правительства.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Модель, как и ранее, постоянно совершенствуется с привлечением акционеров.
Самая последняя версия - V-modell’97. В данное время находится в разработке новая
версия с названием «V-modell 200х», которая должна быть опубликована в 2005 году. Как
и было описано RM-ODP, сочетание с объектно-ориентированными процессами будет
реализовано как часть данной попытки усовершенствования.
Руководство по миграции
Руководство разработано для обеспечения помощи в принятии обоих
стратегических/экономических и детализированных технических решений в случае
предстоящих либо недавно завершенных миграционных проектов. Данное руководство
сфокусировано на замещении продуктов компании Microsoft программными продуктами с
открытым кодом, а также будущее поколение продуктов Microsoft. Были разработаны
специфические сценарии поддержки и обсуждены различные альтернативы миграции.
SAGA версия 1.1 рассматривался как важный интерфейс с руководством по
миграции. Обновления SAGA не найдут отражение в сделанных заявлениях.
DOMEA
DOMEA обозначает «управление документами и электронное архивирование» в
технологических процессах основанных на ИТ. Цель концепции представить электронный
файл. Физические документы должны быть заменены в общественных организациях на
полностью электронные технологические процессы, последовательные процедуры.
(стр.19). Электронные файл являются таким же объектом для юридических и
функциональных требований, как и традиционные документы. С момента публикации
концепции в 1999 году DOMEA утверждается как стандарт для электронных
технологических процессов в федеральных, земельных и муниципальных организациях.
DOMEA составляет значительный ресурс информации предназначенный для требований
общественного управления, в свою очередь, принятый для дальнейшего развития
продукта.
DOMEA претерпевает дальнейшее развитие. Кроме того, организационная
концепция и каталог требований к результатам, модульная концепция будут включать в
будущем дальнейшие модули, которые будут выступать специфическими темами более
детальных организационных понятий. Обновленный проект опубликован на сайте
Координационно-консультационного Агентства Федерального Правительства для
Информационных Технологий в Федеральной Администрации, где он также может быть
обсужден.
Каталог требований концепции DOMEA переводит организационные требования в
функциональные, которые ориентированы на стандарты SAGA с одной стороны, в то
время как с другой стороны, они влияют на процесс обновления документов SAGA.
DOMEA описывает значимые требования для программных продуктов, связанные с
областью управления электронными технологическими процессами. Эти требования в
некотором отношении даже более востребованы, чем SAGA и, следовательно, не
нарушают согласованности SAGA.
1.6.
Процесс развития
Министерство внутренних дел предложило стандарты и архитектуры, которые
должны быть, адаптированы для е-Правительства Германии. Данное предложение
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
основано на сотрудничестве и резюме на форумах SAGA, оценках комиссии экспертов и
финальных набросках авторов. МВД в дальнейшем будет ответственным за координацию
федеральных министерств.
Модель процесса и данных разработанных на основе частных проектов еПравительства общественных организаций. Модели процессов общественной важности
стандартизированы Федеральным офисом управления как центр компетенции для
процессов и организации. …
Решения по развитию основных компонентов принимает МВД после консультации
с федеральными министерствами.
Обновления SAGA появляются регулярно, изменения, отражающие последние
доработки и результаты публикуются на http://www.kbst.bund.de/saga и руководстве по еправительству: http://www.e-government-handbuch.de.
Публичный дискуссионный форум
Публичный форум на http://foren.kbst.bund.de/saga доступен для Интернетпользователей для регистрации и обсуждения тем связанных с приложениями и
дальнейшим развитием SAGA. Результаты обсуждения оценены и учтены в следующей
версии документа SAGA.
Экспертная группа
Федеральное МВД создало экспертную группу из представителей бизнеса и
общественных организаций, и в последствии назначает ее членов.
2.
2.1.
2.2.
2.3.
2.3.1.
Эффект и согласованность приложений
Обоснованность и эффект от SAGA
Классификация и жизненные циклы стандартов
Соответствие стандартам SAGA
Определение соответствия
Соответствие приложения е-правительства (термин е-правительство применяется
как общий термин для любой IT-системы, предоставляющей е-правительственные услуги
федерального правительства; дефиницию термина см. в разделе 4.1.2) стандартам SAGA
оценивается на базе моделей, процедур и стандартов, описанных в SAGA:
a)
b)
c)
d)
Применение стандартизированных моделей процесса;
Учет стандартизированных моделей данных;
Соответствие стандартам и архитектурам, описанным в SAGA;
Использование существующих базовых компонентов.
Чтобы иметь возможность составить исчерпывающий отчет относительно SAGAсоответствия приложения е-правительства – особенно в связи с осуществлением
комплексных, специализированных процессов – приложение, прежде чем оценивать его
соответствие, следует разбить на отдельные компоненты (компоненты – это
нетривиальные, автономные, обменивающиеся модули приложения е-правительства,
имеющие четко определенную функцию в контексте архитектуры всего приложения и
имеющие интерфейсы).
Суб-аспекты SAGA, относящиеся к SAGA-соответствию
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
конкретного компонента, могут быть определены в следующей стадии, с тем, чтобы
можно было учитывать SAGA разумно и адекватно в данной технической ситуации.
Стандарты, которые уместны для обеспечения SAGA-соответствия, зависят от типа
компонентов и могут варьироваться в зависимости от функциональных возможностей,
интерфейса и архитектуры приложения.
2.3.2. Декларация соответствия
В помощь государственным учреждениям, IT-провайдерам и производителям в
Приложении В. содержатся шаблонные формы декларации соответствия (см. с. 158),
которые можно использовать в приглашениях на тендер в качестве основы для
установления SAGA-соответствия приложения е-правительства. Пример заполненной
декларации соответствия доступен в Интернете на http://www.kbst.bund.de/sagakonformitaet.
Прежде чем публиковать приглашение на тендер, заказчик выявляет отдельные
компоненты приложения, различая компоненты продукта (программные средства,
которые просто инсталлируются и конфигурируются) и само-разработанные компоненты.
Соответствие декларируется по каждому компоненту на базе проверочных листов
Приложения В. способом, проиллюстрированным на рис. 2-2.
Приложения е-правительства
Компонент 1
Компонент 2
(саморазрабатываемый )
(продукт)
Проверочный лист
для
саморазвивающихся
компонентов
(Приложение С.2)
Проверочный лист
для компонентов
продуктов
(Приложение С.3)
…
Компонент n
(…)
…
Проверочный лист
для …
Декларация соответствия (Приложение С.1)
Рис. 2-2 Структура декларации SAGA-соответствия и проверочных листов
В декларации SAGA-соответствия заказчики обычно дают обзор компонентов,
определенных для их приложения е-правительства, и прилагают соответствующий
проверочный лист для само-разрабатываемых компонентов и компонентов продукта. Если
поставщики должны получить большую свободу в отношении внедрения приложения еправительства, то также можно оставить на их усмотрение – определить компоненты
самим и классифицировать их в рамках их собственных разработок и продуктов.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
В проверочных листах заказчик может уже конкретизировать соответствующие
аспекты соответствия для данного компонента. Если заказчик желает специфицировать
конкретный стандарт уже на этой стадии, то это тоже может быть выполнено в
проверочном листе.
Поставщик получает декларацию соответствия с заполненными проверочными
листами по выделенным компонентам и констатирует, в какой степени выполнены
спецификации.
2.3.3. Соответствие в случае стандартов с другой классификацией
Индивидуальные стандарты, которые классифицируются как обязательные, не
обязательно должны использоваться в каждом приложении е-правительства. Должно
отдаваться предпочтение обязательным стандартам перед конкурирующими стандартами
при выборе технологий. SAGA-соответствие поэтому достигается применением
конкретного подмножества всех стандартов SAGA, которые подходят для конкретного
приложения е-правительства.
Если для определенных приложений принимаются обязательные или
рекомендуемые стандарты SAGA, то в дополнение могут применяться стандарты и / или
форматы, не перечисленные в SAGA. Если, например, данные ведомости предоставляются
в формате CSV, то те же данные могут дополнительно предоставляться в других форматах,
таких как Microsoft Excel, без нарушения соответствия SAGA.
2.3.4. Ответственность за соответствие
Государственное учреждение, ответственное за приложение е-правительства,
отвечает также за обеспечение соответствия SAGA. Государственные учреждения также
отвечают за изучение способов переноса специальных приложений.
Федеральные министерства устанавливают правила, касающиеся ответственности,
в пределах своей компетенции.
Предоставление тестов на соответствие составляет
совершенствования SAGA (см. раздел 0.2 «Будущие вопросы»).
часть
будущего
2.3.5. Перенос соответствия
Переходная фаза
SAGA является объектом текущего обновления и адаптации к новым требованиям.
Поэтому может случиться, что отдельные приложения е-правительства временно не
соответствуют последней версии SAGA.
Для не соответствующих приложений должны разрабатываться планы переноса
при условии положительного итога в отношении анализа расходов и доходов. Это может
быть только в том случае, если дело касается крупного обновления или пересмотра.
Меры по достижению соответствия
Следующие меры предназначены для поддержки соответствия SAGA:
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
a)
SAGA включается в процессы планирования проекта на ранней стадии;
b)
Соответствие SAGA специфицируется и проверяется, когда утверждаются
проекты;
c)
Соответствие SAGA – обязательный критерий в случаях предоставления
субсидии, в частности, из средств инициативы BundOnline 2005;
d)
Соответствие SAGA специфицируется как обязательный критерий для
государственных контрактов.
2.3.6. Несоответствие
Приложения е-правительства, которые не соответствуют, полностью или частично,
SAGA, подлежат следующим ограничениям:
a)
Использование базовых компонентов может быть ограничено;
b)
Услуги консультаций и рекомендаций со стороны компетентных центров
ограничены или невозможны;
c)
Интерфейсы с такими системами не могут поддерживаться;
d)
Государственные субсидии, в частности, из средств инициативы BundOnline
2005, обычно не доступны;
e)
Интеграция системы в сервис-портал www.bund.de обычно бывает
невозможна.
3.
3.1.
Архитектурная модель для приложений е-правительства
Общие сведения
При архитектурном режиме SAGA имеет следующие цели:
a)
достижение
общего
понимания
современных
архитектур
IT,
информационных технологий и структур е-правительства для облегчения коммуникаций;
b)
выявление возможности сравнения и оценки релевантности, имеющихся
технологии для применения в приложениях е-правительства и получение единой и
устойчивой структуры с помощью данной модели;
c)
а также обеспечение единых стандартов, которые можно использовать при
реализации проектов е-правительства.
Эталонная модель открытой распределенной обработки (RM-ODP – см. в ISO 1996)
– это подход по выбору описания комплексных, распределенных приложений еправительства. Анализ приложения разбит на различные аспекты с целью сокращения
сложности всей архитектуры в целом. Это облегчает понимание системы и управление.
Объектно-ориентированный парадигм (подход к решению проблемы, в котором все
вычисления реализованы в контексте объектов) – основа RM-ODP. Объектная ориентация
способствует созданию четких структур, возможности повторного использования и
способности обновления создаваемых моделей, компонентов и систем.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Предпринимательс
кая точка зрения
Модели процесса и
роли
Информационная
точка зрения
Модули и
интерфейсы
E-правительство
Компьютерная
точка зрения
Данные и
моделирование данных
Железо и
инфраструктура
Техническая точка
зрения
Стандарты и
методики
Технологическая
точка зрения
Рис. 3-1: Аспекты согласно RM-ODP
Аспект предприятия
Анализ
требований
Политика
Информационный аспект
Вычислительный аспект
Технический аспект
Технологический аспект
Функциональные
спецификации
Дизайн
Реализация
Рис. RM-ODP Аспекты и разработка ПО
Модель RM-ODP определяет пять аспектов системы (см. рис. 3-1)
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
a)
Аспект предприятия конкретизирует цели, сферу применения, процессы и
политики для приложения.
b)
Информационный аспект описывает характеристики и семантику данных,
которые должны обрабатываться, т.е. модель данных.
c)
Вычислительный аспект представляет разложение приложения на
функциональные модули и их интерфейсы взаимодействия.
d)
Технический аспект представляет распределение отдельных элементов
системы по физическим ресурсам и их соединениям.
e)
Технологический аспект описывает технологии, применяемые для
внедрения системы.
Пять аспектов могут использоваться как для описания существующих систем, так и
для моделирования новых систем и приложений. SAGA предполагает, но не требует,
использование RM-ODP для описания приложений е-правительства.
Далее, документ SAGA применяет модель RM-ODP к е-правительству Германии.
Результатом являются главы, каждая из которых может быть присвоена тому или иному
аспекту (см. раздел 1.3.5). Это представление аспектов на мета-уровне «Германского еправительства» может использоваться как основа для разработки конкретных моделей для
отдельных приложений е-правительства.
3.2.
Аспект предприятия
Аспект предприятия в приложениях е-правительства включает в себя два
фундаментальных элемента: организационная структура е-правительства в целом и
организационные модели приложения. Здесь описывается вся среда системы и ее цель.
Далее, требования к системе, соответствующие ограничивающие факторы, выполнимые
действия и политики обработки данных получают определения с точки зрения
организации или предприятия. Выполнение включает определение процедур, их правил, а
также действующих сил и их ролей в процессе.
Эффективность информационных технологий очень зависит от интегрированного
взгляда. Это значит, что техническое применение рассматривается, прежде всего, как
процесс, а не как перемещение информационных технологий на передний план.
Сервисы могут и должны описываться в форме моделей технического процесса.
Это означает, что должны рассматриваться все стадии работы от начала до конца, т.е. от
запроса заказчика (гражданина, бизнес-структуры, другого государственного учреждения
и т.д.) до предоставления сервиса. На первой стадии, стадии разработки, эти модели
процесса следует оставить на относительно абстрактном уровне.
Новые предложения дефиниций процессов всегда следует проверять на:
a)
b)
c)
возможность повторного использования;
простоту;
возможность описания их существующими определениями процессов.
Центр компетенции (см. раздел А.9.4 «Компетентный Центр управления
документооборотом, процессами и организацией), занимающийся процессами и
организацией, должен предлагать в этом отношении поддержку.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Глава 4 «Аспект предприятия: основы е-правительства» описывает аспект
предприятия в е-правительстве Германии как модель, которую можно использовать в
качестве базы для создания такого аспекта для конкретных приложений е-правительства.
В разделе 8.1. «Моделирование процесса» SAGA предлагает описательные инструменты
для определения аспекта предприятия.
3.3.
Информационный аспект
Данный аспект определяет структуру и семантику информации системы.
Последующие подпункты включают дефиницию источников информации (отправителей)
и стоков (получателей), а также обработки и преобразования информации системой.
Правила обеспечения целостности и инварианты должны быть описаны дополнительно.
В разделе 8.2 SAGA представлены инструменты, необходимые для определения
моделей данных.
Согласованное определение процесса требует применения общих определений
данных для основных тождеств данных (таких как приложения) и для данных, которые
будут обмениваться между процессами или приложениями.
Модели данных всегда следует проверять на:
a)
b)
c)
возможность повторного использования;
простоту;
возможность описания существующими дефинициями данных.
Компетентный Центр, отвечающий за процессы и организацию, должен оказывать
поддержку в этом отношении.
Глава 5 «Информационный аспект: хранилище схем» согласуется с
информационным аспектом е-правительства Германии и должен учитываться при
создании собственных моделей данных. В разделе 8.2 «Моделирование данных»
классифицируются технологии, которые должны применяться.
3.4.
Вычислительный аспект
В этом аспекте система разбивается на логические, функциональные компоненты,
удобные для распределения. Результатом являются объекты с интерфейсами, на которых
они предлагают и / или используют сервисы.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Клиент
Средний уровень
Связь
Безопасность
Презентация
Интеграционные компоненты
Стойкость (Постоянство) / Back end
Рис. 3-2: Структурный вид – модель уровней
Приложение е-правительства обычно делится на четыре уровня (см. рис. 3-2):
a)
Клиентский уровень представляет собой различные каналы доступа,
отражающие различных пользователей (отвечающие различным пользователям),
устройства, маршруты передачи, а также различные приложения для взаимодействия со
специальными приложениями. SAGA 2.0 обращается к следующим терминальным
устройствам:
1) Веб-доступ через веб-браузеры или специальные браузерные разъемы;
2) Мобильные телефоны и персональные цифровые помощники (PDAs);
3) Внешние системы (такие как ERP-системы индустриальных компаний).
b)
В презентации описывается обработка информации для взаимодействия
клиента и пользователя со специальным приложением. Компонент презентации включает
в себя все стандарты коммуникации с соответствующими терминальными устройствами
клиентского уровня.
c)
Средний уровень включает, в частности, новые разработки по еправительству и в большинстве случаев составляет ядро приложений е-правительства.
Специфическая бизнес-логика специальных приложений связывается вместе в этом
среднем уровне. Презентация технических компонентов сосредоточивается на описании и
обсуждении стандартов для среднего уровня и его интерфейсов, потому что именно здесь
предполагается самая высокая потребность в интеграции в пределах решений еправительства. Средний уровень обрабатывает данные с уровня непрерывного
возобновления.
d)
Уровень непрерывного возобновления обеспечивает хранение данных. Это
обычно выполняется с помощью баз данных. Back-end как собирательный термин
представляет функциональные возможности операционной системы, конкретные базы
данных, а также имеющиеся не соответствующие SAGA специальные приложения,
унаследованные или ERP-системы.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
В пределах этих уровней специальное приложение делится на модули, которые
взаимодействуют через выделенные интерфейсы. Взаимодействие происходит в форме
локальной и удаленной коммуникации между модулями. Базовые компоненты,
определенные в Приложении А., обеспечивают функциональные модули для внедрения
приложений е-правительства.
Должно обеспечиваться безопасное и защищенное взаимодействие всех модулей.
Цели защиты описаны в разделе 9.1.1.
Глава 6 «Вычислительный аспект:
эталонная архитектура программного
обеспечения» описывает общий вычислительный аспект приложений е-правительства,
который можно использовать как основу для создания этого аспекта для конкретного
онлайнового сервиса. В разделах с 8.3 по 8.7 SAGA определяет стандарты и технологии
для реализации вычислительного аспекта. В главе 9 определяются стандарты и модели
безопасного взаимодействия.
3.5.
Инженерный аспект
Инженерный аспект описывает системное обслуживание, необходимое для
распределения объектов с вычислительной точки зрения. Это включает элементы, в
которых выполняются объекты, такие как компьютеры и коммуникационные
инфраструктуры, а также все виды программных платформ для распределенных систем.
В главе 7 «Инженерный аспект: эталонная инфраструктура» дается общее описание
инженерного аспекта приложений е-правительства федеральных учреждений.
Соответствующий аспект конкретного онлайнового сервиса может быть выведен отсюда.
Глава 9 представляет несколько технологий, которые следует освоить для поддержки
сетевой безопасности.
3.6.
Технологический аспект
Этот аспект описывает конкретные технологии, отобранные для внедрения
системы.
В главе 8 SAGA описывает классифицированные стандарты для IT-архитектуры.
Модели и стандарты, соответствующие и поддерживающие безопасность и защищенность,
специфицируются раздельно как вопросы, представляющие общий интерес, в главе 9 по
всем областям IT-архитектуры.
4.
Аспект предприятия: основы е-правительства
В соответствии с определением аспекта предприятия общие рамки компетенции по
е-правительству в Германии будут описаны в данной главе в качестве общей среды для
стандартизированного внедрения приложений е-правительства.
Кроме этого общего рассуждения, будет рассмотрен также уровень процессов.
Будут разрабатываться модели процессов, позволяющие создание базовых модулей в
качестве рамок компетенции для приложений е-правительства.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
4.1. Рамки компетенции для е-правительства в Германии
4.1.1. Дефиниция е-правительства
Когда применяют термин е-правительство, зачастую не вполне понятно, что
имеется в виду и какие возможности оно предлагает. Многие граждане расценивают его
просто как еще одно словечко компьютерного века, тогда как другие считают его
следующим логическим шагом в административных информационных технологиях или
электронным выражением попыток, предпринимавшихся до сих пор для реформирования
администрации.
Согласно инициативе BundOnline 2005, электронное правительство охватывает все
процессы принятия решений и обслуживания в политике, правительстве и администрации,
поскольку эти процессы главным образом основываются на использовании
информационно-коммуникационных технологий. Потенциальные пользователи в этом
контексте сильно варьируются. Они находятся в спектре от модернизации
административных процессов с помощью управления электронным документооборотом
через предоставления административной информации с использованием порталов
государственных организаций в Интернете до комплексных транзакций и интерактивных
электронных услуг для граждан в сети. Цель – предлагать все услуги государственных
учреждений в качестве электронных предложений внешним заказчикам, т.е. гражданам,
бизнес-структурам и другим администрациям. Е-правительство, таким образом,
представляет государственный сектор нарождающегося информационного общества (см.
также пособие по е-правительству – http://www.bsi.bund.de/fachthem/egov/6/htm - глава VI
1, модуль «Глоссарий е-правительства»).
4.1.2. Дефиниция термина «услуга»
Термин «услуга» должен определяться заранее, как предпосылка к пониманию
некоторых форм административных действий в качестве услуг для целей е-правительства.
«Услуга» обычно предоставляется за плату в виде сборов. В рамках обновленного плана
реализации инициативы BundOnline 2005 термин этот был распространен на сферу еправительства.
Когда граждане вступают в контакт с правительством, «услуга» касается полного
выполнения процесса для внешнего пользователя. Это включает процессы, обязательства
и обременения, такие как признание добросовестности тех, кто возражает, приложения
для пособий по безработице или предоставление разрешения на импорт. Для целей
последующего рассуждения, термин «услуга» будет, поэтому, охватывать любые
контакты между гражданами или бизнес-структурами, с одной стороны, и
администрацией – с другой (см. также пособие по е-правительству –
http://www.bsi.bund.de/fachthem/egov/6/htm - глава VI 1, модуль «Глоссарий еправительства», раздел 1.2).
4.1.3. Философия, лежащая в основе е-правительства
Е-правительство открывает новые пути реформирования государственной
администрации. Это касается внутренних отношений в рамках администраций, с одной
стороны, и внешних отношений между администрациями, гражданами и бизнесструктурами
с
другой
(см.
также
пособие
по
е-правительству
–
http://www.bsi.bund.de/fachthem/egov/6/htm - глава 1, модуль «Е-правительство как задача
исполнителей – руководство для государственных администраций»).
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
4.1.3.1.
Обслуживание граждан
Граждане не всегда добровольно контактируют с администрациями.
Административные процессы иногда предполагают большие расстояния и долгое время
ожидания. Контакты с администрацией через Интернет могут, поэтому, предложить
выгоды многим гражданам.
Объединенные сетью компьютерные системы будут частью естественной среды
будущих поколений. Это отражается также большим числом Интернет-пользователей в
возрасте между 14 и 19. Возрастающее проникновение Интернета в обществол также
приведет к росту спроса на онлайновые услуги.
Е-правительство предлагает набор вариантов выбора для развития новых форм
контактов между администрациями и гражданами. Интернет-порталы – это путь
предоставления центрального доступа к администрации. Главной целью инициативы
BundOnline 2005 является совершенствование обслуживания граждан.
Даже и в будущем каждый гражданин должен быть свободен в выборе того, как
связываться с администрацией. Гражданам всегда должна предлагаться возможность
личной встречи с компетентными чиновниками. Следовательно, администрации должны
предлагать многоканальный доступ, чтобы Интернет, call-центры и офисы для граждан
были главными опорами контакта. И call-центр, и офис для граждан в идеале пользуются
порталом в Интернете и лежащей в его основе инфраструктурой приложения. Сам по себе
реальный процесс обслуживания остается не зависящим от канала доступа. Поэтому еправительство может внести вклад в улучшение обслуживания граждан.
4.1.3.2.
Е-правительство как фактор местоположения
Бизнес-структуры часто имеют более частные контакты с администрацией, чем
граждане, например, при процессах сертификации, лицензирования или утверждения, а
также во всем комплексе таможенной и налоговой администрации.
Эти обязательства частично налагаются правительством, при потенциально
громадной административной работе, как для администраций, так и для компаний.
Длинные и сложные процедуры утверждения приводят также к высоким расходам, и для
компаний будет экономичнее, если будут применяться современные информационнокоммуникационные технологии. В интересах обеих сторон рационализировать эти
обменные процессы с помощью е-правительства.
Государственные закупки также предлагают колоссальный потенциал, т.к.
облегченный доступ к процессу тендера может генерировать значительно более сильные
стимулы для компаний.
Качество административных услуг стало фактором глобальной конкуренции за
привлекательные места для бизнеса, которые больше нельзя недооценивать. Учитывая
высокий уровень правил и обязательств для компаний, важнейшим требованием
становится удерживание барьеров на как можно более низком уровне. BundOnline 2005
занимается этой задачей в широком масштабе. Масса услуг при колоссальной
административной работе, например, в секторе таможни, энергично внедряется в качестве
онлайновых процессов.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
4.1.4. Организационные требования
Для обеспечения устойчивого внедрения е-правительства должны выполняться
определенные организационные требования. Наиболее важные из них описаны в
последующих разделах.
4.1.4.1.
Кросс-администрационный подход
Страны
с
федеральной
структурой
сталкиваются
с
проблемами
децентрализованной структуре администрации, когда речь заходит о внедрении еправительства. Децентрализованные административные единицы зачастую в
значительной степени не зависят от центрального правительства. Эта ситуация особенно
удивительна в Германии. В то время как федеральное правительство держит в своих руках
большую часть законодательной власти, за внедрение е-правительства отвечают главным
образом земельные органы и муниципалитеты.
Непосредственно федеральная администрация имеет
лишь несколько
общенациональных задач. Только те функции, которые специально оговорены в
Германской Конституции (статьи 87-89), имеют собственные административные
структуры, такие как Дипломатическая служба, Федеральные Вооруженные Силы,
Федеральная пограничная полиция или Федеральная Администрация госдоходов.
Помимо этих функций, есть и другие национальные задачи, обычно выполняемые
специализированными административными органами, ответственными за всю
Германскую территорию и не имеющими соответствующих административных структур.
Сюда входят, например, Германское федеральное управление расследований,
Федеральное статистическое управление, Германское патентное бюро.
Непосредственно федеральная администрация состоит из:
a)
Верховных федеральных органов, таких как федеральные министерства,,
Офис Федерального Президента и Офис печати и информации Федерального
правительства.
b)
Высших федеральных органов с центральной ответственностью за
конкретную сферу на всей территории Федеративной Республики Германии (например,
Германское федеральное управление картелей)
c)
Федеральные
органы
промежуточного
уровня
с
региональной
ответственностью (например, различные региональные финансовые управления).
d)
Федеральные органы низшего звена с местно-ограниченной деятельностью
(например, главные таможенные офисы)
Федеральное правительство назначает внешние административные органы как
независимые юридические лица с учетом земельных задач, касающихся применения
законов. Эти юридические лица, как корпоративные органы, учреждения и фонды
непрямой федеральной администрации, самостоятельно отвечают за свои сферы
компетенции на всей территории Федеральной Республики Германии и отчитываются
перед министерством.
В отдельных федеральных землях существуют сравнимые структуры. Далее,
города, районы и муниципалитеты составляют третий административный уровень по
своим возможностям как территориальные сообщества с автономными администрациями,
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
которые также выполняют собственные задачи, помимо федеральных и земельных
функций.
Что обычно необходимо, так это сотрудничество, объединение сетью и
координация внутри и между административными уровнями. Первым шагом,
предпринятым на федеральном уровне, было внедрение Информационной сети Берлин –
Бонн (IVBВ), которая представляет собой интранет для верховных федеральных органов.
После апгрейда этой сети до Информационной сети федеральной администрации (IVBV),
она свяжет все федеральные учреждения в безопасную закрытую сеть – колоссальная
проблема для решения – как технически, так и в смысле организации (см. также пособие
по е-правительству – http://www.bsi.bund.de/fachthem/egov/6/htm - глава VC, модуль
«Сетевая платформа для е-правительства»).
Что касается административных процедур, следует избегать замкнутых и
автономных решений при введении новых приложений. Новые решения должны
координироваться между различными уровнями, чтобы достигать максимальной глубины
сервиса и ширины на как можно большей национальной шкале, и чтобы обеспечить
сравнимость административных уровней.
Для того чтобы обеспечить подход в масштабе всей страны, Конференция
Министров-Президентов 26 июня 2003 г. приняла совместную стратегию
интегрированного
е-правительства
под
названием
DeutschlandOnline
(см.
http://www.deutschland-online.de/). В своем совместном докладе федеральное и земельные
правительства и муниципальные администрации согласились создать в Германии
целостный ландшафт е-правительства.
Административные услуги должны предоставляться на многоуровневой основе,
должны быть объединены сетью порталы и совместные инфраструктуры и разработаны
стандарты. В то же время предполагается совершенствовать координацию еправительства и ускорять передачу решений. Этим можно избежать параллельной
разработки, сэкономить средства и интегрировать, модернизировать и оптимизировать
административные процессы.
4.1.4.2.
Оптимизация процесса
Успешное введение и реализация е-правительства требует подготовительной
работы по реструктурированию на уровне процессов. Существующие правила, процессы и
структуры должны быть адаптированы и усовершенствованы, ибо электронная форма
предоставления услуг в противном случае споткнется о те же фундаментальные проблемы,
которые уже встречались при условных документооборотах, не базирующихся на
информационных технологиях.
Существующие административные процессы являются частично результатом
исторического развития и стали чрезвычайно сложными с течением времени в силу
множества мелких изменений. Поэтому, прежде чем внедрять специальные и технические
приложения, рекомендуются следующие меры.
a)
b)
c)
d)
e)
Упрощение процессов и процедур
Отмена государственного регулирования
Укорочение цепочек в процессах
Сокращение интерфейсов
Избежание повторения
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
f)
Сокращение цикла и простоев
(см. пособие по е-правительству – http://www.bsi.bund.de/fachthem/egov/6/htm глава III модуль «Фаза 3 - Анализ»).
Первые шаги уже предприняты в рамках модели сокращения бюрократизма (см. –
http://www.staat-modern.de/). Эта инициатива направлена на достижение скорейшего
упрощения процессов и законодательных положений, касающихся часто используемых
услуг с привлечением множества административных уровней, таких как услуги,
связанные с паспортами и автотранспортными средствами.
4.1.4.3.
Квалификация персонала
Применение и обновление стандартов означает непрерывный процесс обмена
информацией и обучения. Обучение людей пользованию персональными компьютерами
стоит больше, чем сами компьютеры, но дает более устойчивый эффект. Оказалось, что
персонал государственной службы в высокой степени имеет мотивацию к поддержке еправительства. Это ценное качество следует эксплуатировать и повышать в интересах
внедрения е-правительства.
Вопросы, находящиеся в центре внимания, включают интенсивное обучение
персонала, повышение привлекательности работы в государственных администрациях для
IT-специалистов. Деятельность такого рода организуется через Федеральное
Министерство внутренних дел и / или группу проекта BundOnline 2005.
4.1.4.4.
Вовлечение пользователей
Использование е-правительства сильно зависит от признания клиентами
предлагаемых услуг. Полное использование потенциально сэкономленных средств
зависит от того, принимаются ли и используются ли онлайновые услуги потенциальными
пользователями.
Необходимо выявлять на текущей основе, каковы ожидания у граждан, компаний и
государственных учреждений, как специфических целевых групп.
Портфолио услуг и процесс предоставления услуг должны адаптироваться к этим
ожиданиям.
4.1.5. Правовые рамки полномочий
В дополнение к организационным рамкам компетенции должны учитываться
юридические принципы. Наиболее важные из этих требований описаны в предыдущих
разделах. Подробное описание юридических произведенных корректировок имеется в
пособии по е-правительству, выпущенном федеральным правительством и в обновленном
плане реализации инициативы BundOnline 2005 (см. пособие по е-правительству –
http://www.bsi.bund.de/fachthem/egov/6/htm - глава II, модуль «Правовые рамки
полномочий по е-правительству»).
4.1.5.1.
Электронные подписи
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Современное е-правительство требует, чтобы своевременно адаптировались
юридические основания, дабы избежать несовместимости сред передачи данных и
активизировать эффективную безбумажную административную работу.
Юридические корректировки
Юридически обязывающий характер электронных коммуникаций – решающий
фактор успеха внедрения е-правительства. Отсюда – необходимость цифрового решения
для подписи с юридически обязывающим эффектом, т.е. электронной подписи.
Юридические корректировки, необходимые для внедрения электронных подписей, в
Германии в основном проведены. Помимо поправок к Германскому Акту о Подписях c
целью приведения его в соответствие с европейскими требованиями, электронная
подпись интегрирована в соответствующие бланкетные статьи административного и
частного законодательства (см. информацию относительно правовой базы электронной
подписи – http://www.bsi.bund.de/esig/basics/legalbas/).
4.1.5.2.
Распространение электронной подписи
Распространение электронной подписи среди граждан и бизнес-структур и
признание ее с их стороны зависит от нескольких факторов. Расходы на необходимое
оснащение (смарткарта, программное средство, считывающее устройство) еще
относительно высоки и поэтому представляют основное препятствие внедрению
электронной подписи по всей стране.
Далее, все еще есть серьезное отставание населения в смысле использования и
повышенного качества электронной подписи. Кроме того, сами продукты еще не являются
вполне зрелыми. Проблемы при запуске, связанные с разработкой, расхолаживают
потенциальных
пользователей.
Программные
средства,
которые
должны
инсталлироваться для того, чтобы можно было пользоваться электронной подписью, часто
содержат дефекты или вовсе не работают, и непрофессионалам-пользователям
устанавливать их очень трудно. Более того, еще нет стандартизированного чипового
носителя и массовых приложений, которые могли бы проложить путь к проникновению
на рынок.
В апреле 2003 г. правительство и представители бизнеса создали Альянс Подписи с
целью продвижения более прочного распространения многофункциональных смарткарт
подписи и преодоления вышеуказанных препятствий. Этот альянс базируется на идее о
том, что возрастание масштабов использования электронной подписи одинаково выгодно
и государству, и бизнесу, т.к. она будет необходима и для защищенной е-коммерции, и
для приложений е-правительства с юридически обязывающим эффектом. Альянс в этом
отношении опирается на две стратегии. С одной стороны, партнеры по альянсу
договорились принять общие стандарты. С другой стороны, привлекательность альянса
резко возрастет благодаря тому, что все его участники будут применять реалистичные
бизнес-модели.
Первые практические применения предполагают, что смарткарты особенно
привлекательны для граждан, если они могут пользоваться ими для получения как
государственных, так и частных услуг.
4.1.5.3.
Защита данных
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Е-правительство предлагает целый набор вариантов выбора и потенциалов
рационализации в секторе IT. В идеале, данные из самых разных контекстов собираются
только один раз центральной функцией, а в последующем становятся доступными для
каких-либо децентрализованных целей и пользователей.
Однако когда электронные данные обмениваются внутри государственных
учреждений и между ними, то должны учитываться и выполняться требования защиты
данных посредством подходящих технических и организационных мер. Личные данные, в
частности, не могут быть собраны, обработаны или разглашены ни с какой целью, кроме
использования, в ясной форме прописанного в законе.
Пособие федерального правительство по е-правительству включает в себя
отдельный модуль (см. http://www.bsi.bund.de/fachthem/egov/6/htm, глава II, модуль
«Согласующееся с защитой данных е-правительство») с исчерпывающей информацией,
касающейся вопроса о согласующемся с защитой данных е-правительстве.
4.1.5.4.
Свобода от барьеров
В Германии живет более восьми миллионов людей с ограниченными физическими
возможностями, из которых 6,6 млн. имеют тяжелую инвалидность. Люди с
поврежденным зрением и физическими недостатками, в частности, находятся в
зависимости от технической помощи как условия пользования Интернетом, типа больших
экранов или функций увеличительного стекла, строк Брейля, голосового вывода и т.д. Для
оптимального применения этих устройств для приложений е-правительства во время
программирования, проектирования и редактирования должен учитываться целый набор
правил и требований.
1 мая 2002 г. вступил в силу новый Закон о равных возможностях для инвалидов
(BGG), имеющий целью преодоление и предотвращение неудобств для инвалидов,
обеспечение свободного от дискриминации участия инвалидов в социальной жизни и
предоставления этим людям возможности жить автономной, независимой жизнью.
Это также применимо к пользованию Интернетом. Наиболее важные критерии и
ссылки можно найти в Ордонансе о создании свободных от барьеров информационных
технологий согласно разделу 11 Закона о равных возможностях для инвалидов (Ордонанс
о свободных от барьеров информационных технологиях – BITV), вступившего в силу 24
июля 2002 г.
Этот ордонанс специфицирует Руководство по доступу к веб-содержанию 1.0
(WCAG 1) c 1999 в качестве технического стандарта.
Ордонанс о свободных от барьеров информационных технологиях является
обязывающим для государственных учреждений федеральной администрации см.
http://www.bsi.bund.de/fachthem/egov/6/htm, глава IV, модуль «Свободное от барьеров еправительство») и применяется:
a)
К Интернет- присутствию и предложениям
b)
К Интранет – присутствию и предложениям, которые доступны для
широкой публики
c)
К графическим пользовательским интерфейсам на базе IT.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
4.2. Рамки полномочий для приложений е-правительства
4.2.1. Взаимодействие в е-правительстве
4.2.1.1.
Уровни взаимодействия
Услуги е-правительства могут в целом быть разбиты в соответствии с уровнями
взаимодействия, т.е. информационные, коммуникационные и транзакционные.
Информационные охватывают в первую очередь предоставление информации
людям, бизнес-структурам и другим элементам общества. Пользователи на этом уровне
действуют всего лишь как получатели информации. Эта сфера самая разработанная, и
почти во всех государственных учреждениях имеет в Интернете широкое присутствие.
Многие из этих информационных систем дополнены коммуникационными
решениями с предложениями диалога и участия, которые обеспечивают обмен новостями,
сообщениями и информацией. Это дает целый спектр – от простых решений типа
электронной почты или сетевых форумов для обсуждения до более сложных приложений
типа систем видео-конференции для телекооперации. И в этом отношении развитие
администраций Германии можно назвать продвинутым.
Транзакционные
приложения
представляют
собой
высший
уровень
взаимодействия.
Этот
сектор
охватывает
реальное
предоставление
услуг
государственными администрациями. Эти приложения включают, например, электронный
прием и обработку заявлений или заказов и предоставление форм для заполнения и
немедленной отправки нужному получателю непосредственно на компьютере. Системы
электронных платежей или тендеров также относятся к этой категории.
Новые транзакционные услуги уже полностью внедрены. Электронная подпись
является важным элементом, который обеспечивает аутентичность и конфиденциальность
данных, которыми обмениваются разные стороны. Электронный обмен документами с
юридически обязывающим эффектом еще влечет за собой технические и
организационные проблемы для государственных администраций, и удовлетворительное
решение здесь еще нужно искать. Другой неблагоприятный момент – разбросанный
характер распространения электронной подписи во всех частях общества.
Все еще необходима изыскательская работа в отношении регулирования
транзакций. Поэтому последующее изложение сосредоточится на транзакционных услугах
и связанных с ними организационных и технических проблемах, требующих решения.
4.2.1.2.
Отношения взаимодействия
Помимо классификации в смысле уровней взаимодействия, можно также выделить
различных партнеров, вовлеченных в е-правительство.
a)
Правительство – гражданам (G2C)
Эта ситуация относится к электронному взаимодействию граждан с администрацией. Она
охватывает также некоммерческие и неправительственные организации.
b)
Правительство – бизнесу (G2B)
Данный термин охватывает электронные отношения между администрациями и бизнесом
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
c)
Правительство – правительству (G2G)
Это приложение охватывает широкую область электронных отношений между
различными государственными органами и учреждениями сектора государственной
администрации.
Таким образом, услуги предоставляются гражданам, бизнес-структурам и
администрациям. В центре внимания в этом случае находятся отношения взаимодействия
G2C и G2B. Отношения между государственными органами (G2G) регулируются в рамках
соответствующих транзакционных услуг между администрациями и гражданами и / или
бизнесом. Коммуникации внутри государственного учреждения (правительство –
работнику – G2E) в данном контексте четко не рассматриваются.
Рис. 4-1: Общий вид взаимодействий е-правительства
4.2.2. Транзакции в е-правительстве
Как уже упоминалось, услуги государственной администрации охватывают не
только область чистых услуг, но и прав и обязанностей. Функциональная классификация
администраций необходима как предпосылка стандартизации различных типов
административной деятельности – и отсюда возможные транзакции. Обычно
действительные типы транзакционных услуг можно выделять на этой основе.
4.2.2.1.
Типы транзакционных услуг
Германская администрация может быть поделена на функции обслуживания и
вмешательства, основываясь на обязанностях и правовых формах. Различные типы услуг
можно выделить и классифицировать как услуги сервисного типа и услуги
интервенционного типа на базе различных категорий функциональных административных
ветвей.
Услуги востребуются, т.е. инициируются гражданами или бизнес-структурами от
администрации. Услуги включают:
a)
b)
c)
d)
заявления на государственные выплаты
предоставление субсидий
меры по субсидиям и промоушену
процедуры утверждения и лицензирования
Вмешательство – это тот случай, когда администрация вмешивается в правовую
сферу гражданина, покушаясь на свободу гражданина или его имущество и / или налагая
обязательства на гражданина. В этом случае администрацией инициируются
определенные меры. Случаи интервенции таковы:
a)
b)
c)
d)
административные штрафы
уголовное преследование
процессуальные действия
взимание налогов
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
e)
f)
взимание таможенных пошлин
регистрационные обязательства
Государственные закупки представляют собой еще один тип, где правительство
действует как заказчик. Контракты на товары и услуги подчиняются определенным
административным процедурам.
4.2.2.2.
Суб-шаги, действия и роли транзакционных услуг
Отдельные типы транзакций можно разбить на отдельные суб-шаги. Суб-шаги
состоят из одного или более действий, в которые вовлечены различные действующие
силы. Примеры суб-шагов, действий и ролей, относящихся к сфере услуг, описываются
далее. Этот методологический подход может потом применяться в качестве базы для
разработки аналогичных моделей любого другого типа транзакции.
В качестве условия для обращения за услугой, гражданам сначала должна быть
предоставлена возможность получить подробную информацию. За информационным
шагом следует подача заявки. Заявка передается далее государственному учреждению, а
оттуда – тому госслужащему, который отвечает за это. Могут быть запрошены замечания
или информация у других организационных единиц или государственных учреждений.
Как уже говорилось, в этой сфере процессы, возможно, понадобится оптимизировать или
реформировать. За изучением вопроса следует решение. Это решение, опять-таки, может
быть, понадобится переслать другим департаментам или служащим для информирования.
Наконец, решение передается заявителю. Если решение совпадает с просьбой
заявителя, то дело закрывается, и средства выплачиваются, если это применимо. В этом
случае, должен быть возможен постоянный контроль над применением денежных средств.
Процедура заканчивается архивированием как последним суб-шагом.
Если заявитель не согласен с решением, имеются средства правовой защиты в
форме протеста или процессуальных действий, например.
Рис. 4-2: Суб-шаги транзакционных услуг
Это значит, что для сектора услуг могут быть определены эти суб-шаги, по
которым на рис. 4-2 и 4-3 показаны взаимодействия и дальнейшие пояснения.
Каждый суб-шаг включает в себя различные действия и роли, которые отнесены к
различным действующим лицам. Например, суб-шаг «заявления» включает действия
подачи, перевода и получения заявления. Роль заявителя обычно выполняется
гражданином или компанией. В государственном учреждении почта - в идеале
виртуальная – получает заявление и передает его ответственному служащему. Служащий,
который получает заявление, также подтверждает его получение.
По аналогии с этой процедурой, другие суб-шаги включают дальнейшие действия
и роли, которые обобщены в нижеприведенном списке.
Не каждый тип услуги, определенный в разделе 4.2.2.1, должен обязательно
включать все суб-шаги. В зависимости от конкретного процесса суб-шаги могут
выполняться повторно на протяжении существования данного дела.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Суб-шаги
Информация
Действия
Предоставление информации
Запрос информации
Подача заявления
Передача заявления
Получение заявления
Изучение дела
Запрос на информацию
Предоставление информации
Заявление
Обработка
Замечания и
заключение
Оценка информации
Решение
Написание решения
Сообщение решения
Взимание
административных
сборов
Платеж или выплата
средств
Контроль над
применением
денежных средств
Взимание сборов
Роли
Заинтересованный гражданин
Редактор
Заявитель
Почтовое отделение
Служащий
Служащий
Начальник
Заявитель
Почта
Другие служащие
Служащий
Начальник
Другие служащие
Служащий
Начальник
Заявитель
Почта
Плательщик
Касса
Платеж
Получатель платежа
Касса
Изучение дела
Служащий
Запрос на информацию
Начальник
Предоставление информации
Получатель платежа
Почта
Другие служащие
Архивирование
Архивирование
Служащий
Отдел управления
регистрационными записями
Отсылка к другим Трансмиссия данных
Заявитель
процедурам
Служащий
Другие госорганы и
служащие
Рис. 4-3: Суб-шаги, действия и роли транзакционных услуг
4.2.3. Модули осуществления электронных процедур
Анализ типов услуг, пояснявшийся выше, и связанная с ним идентификация субшагов, действий и ролей может использоваться как основа для определения
функциональных модулей, которые – с учетом возможностей необходимой конфигурации
– могут использоваться для внедрения различных процедур с применением
информационных технологий. Потенциальное применение этих модулей зависит от
качества анализа процессов и от выбранной архитектуры программных средств (см. глава
6 «Вычислительный аспект: эталонная архитектура программного обеспечения»).
В сочетании с вышеописанной процедурой можно определить следующие типы
базовых модулей.
a)
Пользовательский интерфейс
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
b)
Анализ различных ролей ведет к необходимости разрабатывать
определенные базовые модули, которые делают возможными функции доступа к
приложению е-правительства. Это включает единый пользоваетльский интерфейс,
который легко запоминается, в качестве функций пользователя и управления ролями и
функций аутентификации пользователей в системе.
c)
Модули действий
d)
Определенные действия осуществляются в форме модулей приложения, при
этом определяются приоритеты, например, на основе их потенциальной частоты
применения в реализации бизнес-логики. Децентрализованные и центральные модули
могут здесь различаться.
e)
Интеграционные и инфраструктурные модули
Определение базовых модулей, выделенных в рамках инициативы BundOnline
2005, более подробно описывается в Приложении А. Разработка специальных приложений
на основе программных компонентов с возможностью повторного использования, таких
как базовые модули BundOnline, излагается в главе 6 «Вычислительный аспект: эталонная
архитектура программного обеспечеия».
5.
Информационный аспект: хранилище схем
Определения стандартов для IT-архитектуры и безопасности данных,
содержащиеся в главах 8 и 9, являются необходимыми, но не достаточными
предпосылками достижения взаимодействия между приложениями е-правительства
федеральной администрации. Технологии, получившие в них определения, не
обеспечивают единой грамматики, семантики и топологии данных. Однако
взаимодействующие приложения требуют именно этой общей семантики для данных,
которыми обмениваются между собой эти системы. Необходимые предпосылки создаются
только тогда, когда используются общепринятые схемы и идентичные дефиниции
элементарных типов данных.
Действующие субъекты е-правительства и их коммуникационные отношения
весьма различны, так что процесс согласования соответствующих схем усложняется.
Первые схемы уже согласованы и получили дефиниции в рамках согласования и
разработки приложений, использующих одно или более взаимодействий, описанных в
разделе 4.2.1.2.
Хотя это означает, что работа, уже выполненная здесь, может частично
использоваться также и в других проектах, но установившейся коммуникационной
платформы, которая раскрывала бы этот потенциал, еще нет.
От имени Комитета по сотрудничеству в автоматической обработке данных для
Сектора федерально-правительственного, федерально-земельного правительства и
муниципальной администрации (KoopA ADV) Бременский Сенатор по финансам создал
руководящую группу, которая координирует и сопровождает все проекты, относящиеся к
вопросу транспорта OSCI. Соответствующее хранилище данных внедряется сейчас.
Находящаяся в Бремене руководящая группа действует, кроме того,
как
контактный партнер и центр компетенции по стандартизации содержания схем по
проектам федерального правительства, федерально-земельного правительства и
муниципальных администраций, типа “xMeld” в качестве стандарта для схем данных и
транзакций для регистрационных приложений.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Координационное и консультативное Агентство Федерального правительства по
информационным технологиям в Федеральной Администрации (KBSt) в начальной стадии
действует как ведущий орган по созданию и администрированию XML-схем
федерального правительства. Это включает, в частности, ответственность за определение
элементарных схем федеральной администрации, т.е. так называемых основных
компонентов. В координации с Бременской руководящей группой планируется создание
многоуровневого хранилища данных, особенно а рамках инициативы DeutshlandOnline.
Это хранилище предоставляет соответствующие XML-схемы и дополняет их
регистрационными данными:
a)
b)
c)
d)
e)
Источник
1) Авторы
2) Контактные партнеры
Документация
Управление версиями
Информация, касающаяся состояния процесса координации
Качественная информация, такая как
1)
2)
Сфера применения
Обязывающий эффект
Центральный XML информационный пункт в настоящее время создается на
вебсайте Координационного и консультативного Агентства Федерального правительства
по информационным технологиям в Федеральной Администрации (KBSt):
http://www.kbst.bund.de/xml-technologie. Там можно также проследить развитие
совместной платформы с руководящей группой в Бремене. Пункт XML-информации
предложит также следующие функции.
a)
Предоставление информации
b)
Коммуникационная платформа для обмена опытом между разработчиками и
пользователями XML- схем
c)
Публикация методик, указаний и директив по использованию схем и ссылки
на них
d)
Каталог XML-проектов федеральной администрации, включающий
информацию по содержанию проектов и контактным партнерам
e)
Сбор основных компонентов
f)
Создание и обеспечение хранилищ
g)
UDDI –сервис для федеральной администрации
h)
Ссылки на другие директории
i)
Хаб для обмена с международными органами и учреждениями, например, в
рамках работы по стандартизации схем для Европейских процессов администрации.
6.
Вычислительный аспект: эталонная архитектура программных средств
В данной главе разъясняются архитектурные решения в рамках SAGA и
описываются получающиеся в результате архитектурные модели индивидуального
специального приложения. Для этой цели сначала вводятся некоторые общие
предварительные условия и требования к программной архитектуре для приложений еправительства. Последующие разделы объясняют основные архитектурные решения и
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
применяют их в форме эталонной архитектуры к типовому, хотя и идеализированному,
специальному приложению. Эта эталонная архитектура программных средств с
вычислительной точки зрения согласно модели RM-ODP 1 описывает техническую
структуру приложений е-правительства. Раздел заканчивается выводами по
технологическому аспекту архитектуры программного обеспечения.
Решение по Java и J2EE как базовым технологиям основывается на главе 8
«Технологическая точка зрения (часть 1): стандарты для IT-архитектуры», т.к. эти
технологии являются обязательными. 2 Однако можно также применять эталонную
архитектуру программного обеспечения и к другим технологиям.
6.1.
Требования и предварительные условия
Вычислительная точка зрения в SAGA была введена для того, чтобы предложить
техническую помощь при проектировании приложений е-правительства, учитывая цели3,
определенные в SAGA, а также философию и требования, описанные в рамках
рассмотрения точки зрения предприятия в главе 4, при особом акценте на повторное
применение и возможность взаимодействия. Одним из главных аспектов в этом контексте
является интеграция специальных и технических приложений в имеющиеся и будущие
архитектуры и инфраструктуры е-правительства, особенно с учетом производных базовых
модулей.
6.1.1. Предварительные условия и рамки эталона для конкретных
администраций
Проектные решения по созданию архитектуры программного обеспечения для
приложений е-правительства должны учитывать определенные требования и рамки
эталона, самые важные из которых будут в общих чертах описаны ниже.
6.1.1.1.
Общеадминистрационные сервисы
Как уже подробно говорилось в главе 4 4 , Германия характеризуется весьма
разнородным ландшафтом государственных организаций. Эта разнородность существует
частично из-за федеральной структуры и, вследствие этого, различных административных
уровней. Далее, ответственность и требования к отдельным ветвям администрации
разнятся от одного административного уровня к другому.
В связи с децентрализацией административной структуры отдельные
административные зоны часто внедряют свои конкретные приложения самостоятельно.
Предоставление онлайновых услуг без несогласованности среды передачи данных –
главная цель е-правительства. Замкнутые решения делают это почти невозможным либо
ведут к повышению стоимости, когда дело доходит до соединению их друг с другом,
особенно в случаях, когда в предоставление услуги вовлечены многие государственные
органы.
6.1.1.2.
Оптимизация процесса
См. Глава 3 «Архитектурная модель для приложений е-правительства», раздел 3.4 «Вычислительная точка
зрения», с.32
2
См. Раздел 8.3.1 «Архитектура приложений с микропрограммами», с.71
3
См. Раздел 1.3.2 «Цель», с.14
4
См. Раздел 4.1.4.1 «Кросс-администрационный подход», с. 37
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
1
Кроме избежания замкнутых решений и параллельной работы по разработке,
рекомендуется реорганизация цепочек процессов. Цель при этом – упростить сложные
административные процедуры, как пояснялось в главе 45.
Упрощение процессов в специальных процедурах дает существенную экономию
средств, когда нужно внедрять особые приложения. Кроме того, можно значительно
снизить восприимчивость к ошибкам, а также расходы на обновление и апгрейд.
Например, следует выявить места, где цифровая подпись абсолютно необходима, а
где достаточно применение авансированной подписи. Любые поправки к применимым
законам должны в таком случае быть рассмотрены в форме соответствующих обновлений.
Пособие по е-правительству, например, предлагает всестороннюю поддержку в
отношении задач оптимизации процессов6.
6.1.1.3.
Требования к защите данных
Еще один главный аспект в решениях по дизайну – это обеспечение соблюдения
требований защиты данных. Несмотря на все преимущества центрального, не резервного
хранения данных, должны быть приняты меры к обеспечению соблюдения всех
применимых законов при хранении и обработке личных данных.
Архитектура программного обеспечения должна, поэтому, включать определенные
системы безопасности, с тем, чтобы исключить манипулирование данными и атаки
хакеров.
Более подробную информацию относительно вопроса о согласующемся с защитой
данных е-правительстве см. в пособии по е-правительству7.
Помимо уже выделенных и описанных предпосылок и критериев, существуют и
другие условия, которые влияют на архитектурные решения, которые должны
приниматься, и на выбираемую архитектуру программного обеспечения. Эти условия
рассматриваются в документах, которые перечисляются в разделе 1.5 «Отношение к
другим документам е-правительства» на стр. 17; в этих документах четко различается
сфера применения таких документов, с одной стороны, и сфера применения SAGA – с
другой.
6.1.2. Взаимодействие и возможность повторного использования
Как уже говорилось, именно согласующееся со средой внедрение транзакционных
услуг влечет особые организационные и финансовые требования к отдельным
государственным учреждениям. Что зачастую нужно – это сотрудничество,
объединяющее учреждения между собой посредством соединения существующих особых
приложений и использования компонентов программных средств с большим объемом
стоимости, таких как платформа платежей или модули для поддержки электронных
подписей.
См. Раздел 4.1.4.2 «Оптимизация процесса», с.39
См. пособие по е-правительству (http://www.bsi.bund.de/fachthem/egov/6.htm), глава V D, модуль:
«еСтратегия, анализ и дизайн процессов»
7
См. пособие по е-правительству (http://www.bsi.bund.de/fachthem/egov/6.htm), глава II, модуль:
«Согласующееся с защитой данных е-правительство»
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
5
6
Возможность повторного использования компонентов программного обеспечения
и взаимодействие отдельных приложений и компонентов – непреложные условия для
решения этих проблем.
Применение стандартизированных и повторно используемых процессов в рамках
единой и стандартизированной архитектуры программных средств в е-правительстве
могут в долгосрочной перспективе снизить стоимость. Этот стандартизированный подход
ведет к унифицированным интерфейсам при проектировании и внедрении программных
проектов, так что специальные приложения могут отвечать требованиям и целям SAGA.
С этой целью в главе 4 8 основные модули были выделены в первый этап. Эти
основные модули должны быть интегрированы в архитектуру программного обеспечения,
как предпосылка их использования совместно с внедрением специальных приложений.
Архитектура программного обеспечения не может носить произвольный характер,
напротив, она должна удовлетворять определенным требованиям и критериям, чтобы
достигать поставленных целей.
6.1.3. Дальнейшие основные требования к архитектуре программного
обеспечения
Помимо конкретных целей разработки специальных приложений, которые могут,
например, быть выведены из особых технических требований, любая система, которую
нужно разработать, должна также выполнить ряд общих требований. Эти общие цели
и/или основные требования к специальному приложению должны учитываться в
решениях по дизайну, которые должны приниматься в рамках архитектуры программного
обеспечения.
a) Безопасность
Конфиденциальность, аутентичность и репродуктивность, а также соблюдение
Федерального Акта о защите данных и соответствующих глав пособия по е-правительству,
касающихся безопасности, должны быть обеспечены при использовании приложений еправительства.
b) Возможность повторного использования
Возможность повторного использования е-правительства или одного из его
компонентов является одним из центральных требований, которое можно выполнить,
соблюдая и используя SAGA. Тем самым избегается разработка излишних приложений
для аналогичных или идентичных услуг, поэтому может быть достигнута экономия
средств. Кроме того, использование опробованных и протестированных модулей
повышает качество всей системы.
c) Гибкость
Приведение в соответствие с новыми критериями и апгрейды легко выполнимы
и/или по приемлемой стоимости.
Приложения е-правительства должны проектироваться таким образом, чтобы их
модификации или поправки к ним – в результате, например, изменений в
См. Раздел 4.2.3 «Модули для реализации электронных процедур», с. 47
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
8
законодательстве, оптимизации процессов или использования другими государственными
учреждениями – могут выполняться эффективно и по приемлемой цене.
d) Открытость
Для того чтобы упростить интеграцию существующих или новых систем, та
система, которая используется, должна включать четко определенные и
документированные интерфейсы.
Многие государственные учреждения уже эксплуатируют унаследованные системы
с интенсивной стоимостью. Коммуникационные протоколы, определенные в SAGA,
должны, поэтому, обеспечивать плавную интеграцию, особенно с учетом унаследованных
систем. Открытость приложения е-правительства – один из важнейших факторов его
успешного использования.
e) Масштабируемость
Распределение приложения е-правительства или его отдельных компонетов должно
быть возможным без каких-либо проблем. Это единственный путь обеспечения текущего
использования приложения эффективно и продуктивно по мере возрастания этого
использования. Особенно в случае приложения е-правительства, оперируемого
централизованно, количество государственных учреждений, его использующих,
неопределенно, поэтому должна обеспечиваться его будущая экономичная
масштабируемость, когда возрастет количество государственных учреждений и
пользователей.
f) Производительность
Короткое время отклика приложения чрезвычайно важно для обеспечения его
широкого признания гражданами и бизнес-структурами. Сложные транзакции часто
требуют обработки больших количество данных. Успешное применение приложений
зависит от удобного для пользователя и производительного предоставления данных.
g) Доступность
Доступ к приложениям е-правительства должен обеспечиваться постоянно.
Постоянно доступное приложение говорит о надежности и заслуженном доверии, поэтому
граждане и бизнес-структуры все более охотно пользуются этим приложеним и
предоставляют – обычно конфиденциальные – данные, необходимые для транзакции,
представленной приложением.
h) Толерантность к ошибкам
Система должны быть способна справляться с непредвиденными и неисправными
состояниями системы. Ошибки или непредвиденные события не могут вести к поломке
или к неконтролируемому поведению системы, которое пользователь не может понять.
Как и доступность, толерантность к ошибкам является важным параметром
доверия к приложению. Безупречная, прозрачная работа приложения – важнейшая
предпосылка доверия пользователя к сложным транзакциям.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
i) Способность к обновлению информации
Эксплуатация и обновление систем е-правительства должны быть как можно более
легкими. Внешние эксперты, которые не занимались разработкой системы, должны быть
способны обеспечить эффективное сопровождение системы и обновление даже без
удлинения времени на ознакомление с ней.
Данный перечень приблизительно отражает приоритеты отдельных требований к
техническим аспектам программного обеспечения. Конкретное взвешивание отдельных
аспектов зависит от факторов, которые следует выделить и оценить при разработке
концепции конкретного специального приложения. В случае с приложениями с очень
высокой скоростью доступа, например, доступность, вероятно, более важна, тогда как
вопросы безопасности, скорее всего, будут более высоким приоритетом в сочетании со
сложными процедурами утверждения и лицензирования.
6.2.
Архитектурные решения
Архитектура программного обеспечения, описываемая здесь, охватывает несколько
фундаментальных проектных решений. Это обязательное использование парадигм
разработки объектно-ориентированных программ и на этой основе компонентный подход
к разработке программ.
Компонентная разработка программ
В контексте данной эталонной архитектуры программного обеспечения,
программные компоненты определяются точно таким же образом, как в разделе 2.3.1 на
стр. 26.
Компонентная разработка позволяет компилировать программы из существующих
компонентов и повторно их использовать. Предполагается, что эта система даст несколько
положительных эффектов, в частности:
a)
b)
c)
d)
e)
более быструю разработку и предоставление приложения
более низкие цены
более высокое качество
менее сложную структуру
гибкие системы приложений и современные системные архитектуры
Однако применение компонентной разработки программ имеет не только
положительные последствия. Стоимость разработки и потребности первоначально более
высокие, есть вероятность дополнительных расходов на обучение, а проектные ошибки
могут вести к нежелательной зависимости от компонентов, что неблагоприятно влияет на
системную архитектуру. Хотя преимущества, скорее всего, почувствуются через средний
или длительный срок, а с негативными эффектами за короткое время не справиться,
сектор е-правительства, тем не менее, превосходно подходит для применения
программных компонентов благодаря времени проектных циклов и высокой доле сходных
и сравнимых приложений. Для того чтобы разработать устойчивые, повторно
используемые компоненты, необходимы четкие функциональные дефиниции, чтобы
создать максимальные выгоды благодаря сокращению параллельной разработки.
Разделение представления и бизнес-логики
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Разделение представления и бизнес-логики предлагает техническое решение для
оптимальной поддержки множества презентационных каналов, например, различных
типов браузера или мобильных устройств типа персональных цифровых помощников
(PDA). Помимо этого аспекта, разделение представления и бизнес-логики значительно
повышает качество кодовой структуры, тем самым существенно повышая возможности
обновления и диагностики неисправностей, гибкость, возможность повторного
использования и воспроизведения, снижая, в то же время, стоимость в среднесрочной
перспективе. Такое разделение делает потенциально возможным
распределение
приложения по нескольким серверам, когда один сервер отвечает за уровень
представления, а другой – за бизнес-логику. Это оказывает положительное влияние на
режим функционирования в плане безопасности, способности к обновлению и
масштабируемости. Особое внимание следует уделить здесь коммуникации, т.к.
распределение по принципу менее чем оптимум неблагоприятно воздействует на качество
функционирования.
Разделение логики бизнеса и данных
Разделение логики бизнеса и данных приводит к приложениям, являющимся
независимыми от типа базы данных (в смысле независимости реляционной базы данных
от объектно-ориентированной). В то же время функциональные возможности прямо не
зависят от базы данных через абстракцию и производительность, например, с помощью
использования кэша.
Четырехуровневая архитектура
Реализация вышеуказанных аспектов ведет к многослойной архитектуре с
четырьмя уровнями. Внедрение специального приложения по уровням с включением
компонентов требует четкого назначения компонентов к конкретным уровням. Это
облегчает классификацию компонентов и подразумевает формальные определения их
функциональных возможностей.
Отдельные слои многоуровневой архитектуры – это клиентский уровень, уровень
представления, средний уровень и уровень непрерывного возобновления/back end.
a)
Клиентский уровень – это где взаимодействуют пользователи с
приложением. Становятся видимыми данные, обрабатываемые уровнем представления, а
также пользовательский интерфейс.
b)
Уровень представления отвечает за представление данных приложения
(например, в виде вебсайта)
c)
Средний
уровень,
называемый
также
уровнем
приложения,
приспосабливает самые важные компоненты для реализации логики приложения, вне
зависимости от их представления. Именно здесь контролируется последовательность
программы. Данные из уровня непрерывного возобновления обрабатываются в
соответствии с этим и передаются далее на уровень представления, где удостоверяются
вводы пользователя или, например, предоставляется авторизация. Необязательная часть
этого уровня интегрирует центральные компоненты, унаследованные или ERP-системы,
если необходимо. Внешние сервисы могут получать доступ к приложениям через
интерфейсы приложений, без необходимости использования уровня представления.
d)
Уровень непрерывного возобновления отвечает за хранение объектов
данных. Он абстрагирует из базы данных. Back-end как собирательный термин
представляет собой функциональные возможности операционной системы, конкретные
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
базы данных, а также существующие не соответствующие SAGA, специальные
приложения, унаследованные или ERP-системы.
Рис. 6-1: Пример четырехуровневой архитектуры для приложений е-правительства
Рисунок 6-1 – это графическая иллюстрация структуры. Она показывает структуру
уровня представления, состоящего из сервера приложения для целей представления и
соответствующих индивидуальных компонентов, таких как Serviet Engine. Сервер бизнесприложений в среднем уровне составляет магистральную сеть приложения и, через
интерфейсы приложений, позволяет другим приложениям пользоваться специальным
приложением как сервисом.
Средний уровень можно пропускать в случае простых приложений, которые не
являются ни транзакционными, ни использующими специальные интегративные
функциональные возможности. Однако для целей последующего описания
идеализированного типичного специального приложения этот случай более подробно
рассматриваться не будет.
Java и J2EE
Многоуровневая архитектура внедряется предпочтительно с помощью языка
программирования Java, как описывается в разделе 8.3.1 «Архитектура приложений с
микропрограммами» с точки зрения технологии на стр. 71. Решение в пользу Java
основывается на ее не зависимой от платформы оптимальной поддержке объектноориентированной программной методики, стабильности среды исполнения и большого
числа бесплатных и коммерчески доступных API. Можно заключить, что применение Java
обеспечивает максимальную поддержку многоуровневой архитектуры.
Сосредоточение на среднем уровне и применении Java логически предполагают
использование J2EE. Результатом является детальная техническая парадигма для
производства программных средств и основа структуры приложений.
Структура приложений определяет стандартное поведение и структуру всех
приложений с помощью группы абстрактных и конкретных классов, настроенных друг на
друга (абстрактные классы определяют интерфейсы только когда они заполняются
конкретными методами суб-класса; конкретные – это законченные, полностью
реализованные классы, характеризующие конкретную функциональную возможность).
Новые приложения создаются выведением конкретных классов из абстрактных и
присоединением независимых, связанных с конкретным приложением, классов.
Аналогичные задачи преследуются в отношении целей структур и компонентов
приложений. Системы приложений должны также вести к возможности повторного
использования компонентов программы. Это, однако, достигается наследованием на
уровне классов. Но рост продуктивности и качества во время разработки интерактивных
систем приложений сталкивается также с определенными недостатками, такими как
высокая степень сложности и негибкие структуры, что может привести к непредвиденным
проблемам во время разработки приложения. Однако, компонентный подход делает
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
привлекательную структуру приложений для повторного использования программных
структур гибкой и поэтому представляет идеальное дополнение.
Слабые соединения между распределенными компонентами
Уровни и компоненты присоединяются к гармоничной общей системе внутри
многоуровневой архитектуры стандартизированными идентичными интерфейсами. Это
необходимая предпосылка для сведения вместе приложений из любых компонентов.
Более того, слабое соединение распределенных компонентов должно быть
предпочтительным.
Связь между компонентами через вызовы подпрограмм или веб-сервисы
Сетевые протоколы на базе HTTP используются для коммуникации между
компонентами клиентского уровня и уровня представления. Компоненты уровня
приложения сообщаются через вызовы или интерфейсы, определяемые структурой
компонентов. В случае коммуникации с распределенными компонентами или с
компонентами, которые, ввиду их специфического приложения, доступны лишь как
центральные компоненты, коммуникация продолжается через веб-сервисы даже на
среднем уровне.
Интерфейсы данных на базе XML
Интерфейсы данных с внешними системами обычно должны реализоваться через
XML и соответствующие дефиниции схем (см. главу 5 «Информационная точка зрения:
хранилище схем»).
6.3.
Эталонная архитектура для приложений е-правительства
Свойства архитектуры, описанные в предыдущей главе, рассматриваются более
детально и применяются на базе эталонной архитектуры для идеализированного типового
специального приложения. Как объяснялось в разделе об архитектурных решениях, это
специальное приложение конфигурируется в качестве компонентной системы согласно
четырехуровневой модели.
6.3.1. Основные функциональные возможности используемых
компонентов
Свойство, общее для всех компонентов – это то, что они могут помогать себе
общими сервисами инфраструктуры – поддержкой тестовых методов, логином и
мониторингом. Эти сервисы обеспечивают определенной данной инфраструктуре
интерфейсы компонентов. Информацию по внедрению этих базовых функциональных
возможностей можно найти на http://www.kbst.bund.de/saga-tools.
Поддержка тестовых методов
В дополнение к рекомендациям по структурам программного обеспечения
существуют указания по вопросам организации процессов. Важный этап отладки и
тестирования приложения, например, часто отделяется от этапа собственно разработки, а
иногда даже игнорируется. Тестовые сценарии должны рассматриваться и прочно
интегрироваться в процесс разработки еще в течение фазы спецификаций рабочих
характеристик.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Логин
Рекомендуются единые процедуры обращения с системной информацией для
облегчения функционирования приложения. Для этой цели должны быть готовы
стандартизированные компоненты и форматы log. Размеры log-файла не должны расти
бесконечно, а должны также охватывать определенный приемлемый период времени. Это
требует механизма управления log-файлом, который может основываться на его
параметрах или на временных аспектах. При нормальных условиях работы никакая
информация, кроме как об ошибках, не должна записываться в log-файле. Чтобы сделать
возможной регистрацию данных, которые, например, нужны для целей анализа, должен
быть готов механизм, который делает доступными уровни log, а также активизацию и
дезактивизацию log-сообщений с определенных уровней. Используются эти log-уровни
для классификации событий с учетом их релевантности в рамках структуры
приложения/функции компонента. С этой целью следует четко выделить в фазе
проектирования архитектуры программного обеспечения те случаи, когда нужно
применять log-уровни.
Мониторинг
Мониторинг в контексте данного раздела – это мониторинг ресурсов отдельной
системы во время текущих операций с учетом, например, их состояния или качества
функционирования. Сервис мониторинга проектируется как инструмент для системных
операторов, помогающий им определить текущее состояние системы. Это требует
определения операционных условий и состояний и внедрения удобных механизмов на
уровне приложения, чтобы обеспечивать информацию о состоянии системы.
Управление конфигурацией
Этот термин в данном контексте относится к системной и/или системно-ресурсной
конфигурации. Во всех случаях, когда это возможно, один и тот же механизм должен быть
принят для всех компонентов, позволяя центральное конфигурирование всех компонентов.
Должно быть возможно конфигурировать важные системные параметры даже во время
прогона системы. Решения приложений в большинстве случаев базируются на статичных
конфигурациях, сохраняющихся на так называемых файлах свойств. Повторная
конфигурация, например, log-уровня часто требует повторного запуска приложения.
Этого следует избегать.
Трактовка ошибок
Если компонент выходит из строя и перестает работать с ошибкой, то должна быть
возможность отследить ошибку на протяжении всего пути обработки. Это значит, что log
ситуации ошибки должен показывать происхождение ошибки. Эта информация обычно
доступна с обычного stacktrace приложения. Более того, log должен содержать как можно
больше дополнительной информации, с тем, чтобы проблемы быстро выявлялись и
решались. В случае с веб-приложениями, например, опробованный и протестированный
подход должен сформулировать полный запрос (включая URL), который вызвал ошибку.
Безопасность
Компоненты, дающие доступ к критически важным или чувствительным данным
или выполняющие письменные транзакции по таким данным, должны отвечать
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
требованиям безопасности, рассмотренным в главе 9 «Технологическая точка зрения
(часть II): стандарты безопасности данных» на стр. 92 и последующих.
6.3.2. Структура типового специального приложения
На базе существующей инфраструктуры государственного учреждения должны
внедряться специальные приложения, которые легко можно интегрировать в эту
инфраструктуру, с одной стороны, будучи при этом способными кооперироваться с
существующими приложениями – с другой. Это кооперирование не только включает в
себя коммуникацию, но прежде всего стремится к технической идентичности так, как это
намечено в SAGA для того чтобы свести к минимуму расходы на инсталляцию,
сопровождение/обновление и внедрение. Когда проектируется внедрение специального
приложения, компоненты, которые нужно вновь разработать, и сферы, в которых можно
повторно использовать уже существующие компоненты, отбираются с точки зрения
концепции компонентов. В этом смысле, основные компоненты, упомянутые в
Приложении А «Основные модули инициативы BundOnline» на стр. 108 и последующих,
следует проверить прежде всего на предмет их пригодности.
Специальное приложение, о котором идет речь, осуществляет транзакционную
услугу е-правительства и тем самым основывается на фокусной ориентации, описанной в
точке зрения предприятия в разделе 4.2.1.1 «Уровни взаимодействия» на стр. 42.
Типичные коммуникации происходят между клиентским уровнем, веб-браузером и
уровнем представления. Определенные компоненты уровня представления преобразуют
данные – которые могут, например, существовать в формате XML – в формат HTML,
когда это нужно веб-браузеру.
Реальная логика приложения реализуется на среднем уровне. Задачи вебприложения включают, например, удостоверение пользовательских вводов, сравнивание
их с соответствующими запасами данных, обработку и передачу данных на уровень
представления.
Средний уровень - также и там, где происходят коммуникация и логическая
интеграция базовых компонентов, таких как е-платеж и безопасность данных, а также
сервисов «один за всех» (OFA). Сервисы специального приложения предлагаются
внешним приложениям через интерфейсы приложения. В соответствии с бизнеспримерами, упомянутыми в разделе А.1.3 на стр. 110 и последующих, базовый компонент
е-платежа требует, чтобы он эксплуатировался централизованно Федеральным
финансовым офисом. Поэтому специальное приложение сообщается через веб-сервисы на
основе SOAP (см. с. 86). Базовый компонент безопасности данных оперируется
децентрализованно и, в соответствии с бизнес-примерами, охватывает аспекты
безопасности, касающиеся обмена документов и коммуникаций по электронной почте.
Помимо применения SOAP, коммуникации с распределенными компонентами
используют также RMI - Инициирование Удаленного Метода (см. стр.86) или сервис
сообщений (см. стр. 72). Компоненты уровня непрерывного возобновления осуществляют
доступ к базе данных и стратегии использования кэша.
В реальности специальное приложение всегда должно наполняться решениями
интеграции, т.к. оно должно сообщаться с существующей системой данных. Эти
интеграционные компоненты, показанные на рис. 6-2 «Архитектура справочного
программного обеспечения», расположены непосредственно на среднем уровне. Для этих
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
целей компоненты, которые нужно разработать, будут предлагать способы коммуникации
с другими системами, такими как решения SAP.
Рис. 6-2 «Архитектура справочного программного обеспечения»
Реализация реального специального приложения включает, главным образом,
внедрение выделенных компонентов и их коммуникацию с вышеупомянутыми базовыми
функциональными возможностями. Требования, предъявляемые к качественным
компонентам программного обеспечения, высоки, в смысле четкого определения функций,
устойчивости и документирования в свете предполагаемой возможности повторного
использования. Заключительный этап – собрать компоненты в исполнимое приложение.
Эта работа может исходить из существующих структур , с одной стороны, и управления
конфигурацией, которое поддерживается всеми модулями – с другой.
6.4.
Выводы из архитектуры программного обеспечения
Предпосылки и архитектурные решения, рассматриваемые в данной главе, имеют
всякого рода последствия для рассмотрения инженерного и технологического аспекта в
последующих главах.
Архитектурные решения частично документируются в соответствующих разделах
в качестве обязательных стандартов. Это включает, например, спецификацию J2EE в
разделе 8.3.1 «Архитектура приложения с микропрограммными средствами».
7.
Инженерный аспект: эталонная архитектура
Выбор соответствующей архитектуры является решающим фактором успеха, когда
речь заходит о планировании, проектировании и эксплуатации приложений еправительства. Стабильная и защищенная IT-инфраструктура – главная предпосылка
функционирования приложений е-правительства с высокой степенью надежности.
Сегодняшние требования защиты данных, безопасности данных, эффективности и
доступности е-правительства устанавливают высокие стандарты для операторов
приложений и инфраструктур.
Эталонная инфраструктура для приложений е-правительства моделируется на
основе точки зрения инжиниринга согласно RM-ODP (см. главу 3 «Архитектурная модель
приложений е-правительства», стр. 34) и описывает пакетирование системных блоков и их
подключение. Хотя стандарты и технологии описываемой эталонной инфраструктуры не
составляют часть инженерного аспекта в строгом смысле, тем не менее, они включены,
для того чтобы сделать представление как можно более реалистичным. Нижеследующие
пояснения можно разбить согласно подходу сверху вниз к инженерному аспекту одного
специального приложения.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Рекомендации Федерального офиса Германии по информационной безопасности
(BSI), касающиеся безопасности приложений е-правительства (см. пособие по еправительству на http://www.e-government-handbuch.de/) и Пособия по базовой защите IT
(см.: http://www.it-grundschutzhandbuch.de/) заслуживают особого внимания в данном
контексте. Если для специальных приложений выявляется более низкий спрос на защиту,
то к какой-либо данной инфраструктуре могут применяться меньшие требования, чем те,
которые учитываются в нижеследующем эталоне.
Не каждому государственному учреждению требуется собственная полная
инфраструктура е-правительства. Более млкие учреждения вполне могут пользоваться
компьютерными центрами внешних IT-сервис провайдеров или других, более высокого
уровня, государственных учреждений.
7.1.
Проектирование инфраструктуры е-правительства
Введение эталонной инфраструктуры в SAGA служит цели определения
инфраструктурных предпосылок, необходимых для функционирования приложений еправительства, и требуемой системной архитектуры. Благодаря определению параметров
или эталонной инфраструктуры в смысле операционной среды должны достигаться
следующие цели:
a)
Физическая защита систем
b)
Максимальная доступность систем
c)
Повышение безопасности систем и системных компонентов через
классификацию на базе запроса об их защите
d)
Классификация систем и системных компонентов в соответствии с
отдельными зонами безопасности
e)
Масштабируемость систем и инфраструктур
f)
Простое обслуживание, эффективное сопровождение и обновление сложных
приложений е-правительства и системных компонентов операционным персоналом
На рис. 7-1 показан общий целостный вид на распределенное приложение еправительства с областями пользователя, сети и инфраструктуры.
Рис. 7-1: Инженерный аспект приложения е-правительства
И сетевая, и пользоваетльская области обычно находятся вне контроля оператора
приложения е-правительства, и поэтому не являются предметом рассмотрения здесь.
Инфраструктурная область же, напротив, контролируется оператором и должна
характеризовать удобную архитектуру и системную структуру, дабы отвечать
операционным требованиям, предъявляемым к приложениям е-правительства.
Требования к компьютерному центру и его IT-инфраструктуре описываются ниже.
7.1.1. Физическая инфраструктура
Защита систем от внешних воздействий, элементов и несанкционированного
доступа требует предоставления подходящего пространства. Компьютерные центры,
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
предназначенные для размещения приложений е-правительства, должны, поэтому, как
минимум, обладать следующими качествами.
a)
Пожароустойчивое, структурно закрытое безопасное пространство,
защищенное от радиопомех
b)
Контроль доступа, включающий аутентификацию персонала
c)
Система пожаротушения с некоррозийными и нетоксичными реактивами
для тушения
d)
Резервное электропитание, в том числе бесперебойное питание (UPS)
e)
Резервная система кондиционирования воздуха
f)
Средства резервного копирования данных в пожароустойчивом подвале за
пределами компьютерного центра
7.1.2. Зональная концепция и коммуникационные отношения
Системы внутри компьютерного центра размещаются в различных зонах,
определяемых на базе соответствующих требований целостности и безопасности сервисов
и данных соответствующих зон. Чтобы обеспечить охват зональной концепцией общих
требований по защите приложений е-правительства, в инфраструктуре компьютерного
центра следует внедрить, как минимум, четыре описываемых ниже зоны.
Функционирование сложных приложений е-правительства может потребовать и большего
количества зон. Они должны быть физически строго раздельными. Это значит:
a)
Любой сетевой компонент (маршрутизатор, переключатель, хаб и т.п.)
может использоваться только как интерфейс между одной зоной и другой, так, чтобы
какой-либо компонент сети передавал только данные, касающиеся двух зон,
непосредственно подключенных к нему, или исходящие из этих зон. Это препятствует
смешению потоков данных в случае неисправности или же намеренной атаки
b)
Серверная система может вмещать только системы одной зоны. Это
означает, что распределенные приложения должны работать на серверных системах в
других зонах.
c)
Серверная система с приложениями е-правительства, требующими
коммуникационных подключений к нескольким зонам, должна включать в себя
соответствующее количество физически и логически раздельных сетевых подключений
(например, множественные сетевые карты). Система тем самым исключает переход из
одной зоны в другую.
Зона информации и сервисов
Зона информации и сервисов охватывает ту часть сети, которая расположена
между Интернетом и другими зонами сети. Эта зона содержит серверы, к которым могут
иметь доступ внешние сети, или которые, со своей стороны, пользуются услугами
внешних сетей. Дальнейшие информационные зоны следует устанавливать, если должны
эксплуатироваться системы с другим уровнем безопасности.
Коммуникация между системами информационной и сервисной зон, с одной
стороны, и системами зон логики и обработки - с другой должна защищаться каналами
кодированной связи.
Зона логики и обработки
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Системы этой зоны обрабатывают данные из зоны данных и делают их
доступными для пользователей через системы зоны информации и сервиса. Прямая связь
между внешними сетями – такими как Интернет – и зоной логики и обработки не
разрешается.
Зона данных
Зона данных содержит все системы, в которых данные хранятся и делаются
доступными на продолжительное время. Доступ к этой зоне разрешен только из зоны
обработки и из зоны управления. Прямой доступ из внешних сетей не разрешается ни при
каких обстоятельствах. Более того, ни к каким другим зонам, кроме зоны управления, нет
активного доступа изнутри этой зоны.
Зона управления
Зона управления содержит все системы, которые нужны для административных
целей или для мониторинговых систем в других зонах. Более того, эта зона может также
содержать сервисы центрального администрирования пользователя или аутентификации.
Поэтому доступ из зоны управления к другим зонам и наоборот разрешен.
Доступ изнутри внешних сетей к зоне управления не разрешается ни при каких
обстоятельствах.
Резервное копирование данных
Каждая зона должна включать свои собственные компоненты резервного
копирования данных. Данные информационной зоны должны получать резервную
поддержку через защищенные каналы связи.
7.1.3. Сетевой доступ и контроль доступа
Системы контроля доступа контролируют разделение отдельных зон в рамках
компьютерного центра, а также доступ со стороны внешних сетей и к этим внешним сетям.
Для этих целей могут применяться различные технологии.
Интерфейс между зоной информации и сервиса и внешними сетями – это самый
критически важный для безопасности аспект и потому защищенный сочетанием
множества механизмов безопасности. Разделение на различные сетевые сегменты и
области адресов осуществляется здесь на уровне сетевого протокола. Внутренние сетевые
адреса маскируются в сетях TCP-IP на базе протокола NAT – Трансляции Сетевых
Адресов, и поэтому не опубликовываются во внешних сетях.
Далее, могут применяться шлюзы приложений, которые полностью изолируют
коммуникации, проверяют достоверность потоков данных на уровне приложения и, когда
необходимо, осуществляют подтверждаемое протоколом ре-генерирование запросов.
Коммуникационные отношения между внутренними зонами также подчиняются
системам контроля доступа. Для адекватного контроля доступа к чувствительным
областям зоны логики и обработки, а также зоны данных, следует использовать
межсетевые шлюзы, в силу их большого набора опций фильтров. Эти межсетевые шлюзы
работают на базе динамичных пакетных фильтров (режимная инспекция) и способны
осуществлять мониторинг не только отдельных пакетов, но и коммуникационных потоков
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
из множества пакетов. Динамичные пакетные фильтры делают возможным
подтверждение достоверности сетевых подключений не только на базе неизменных
правил, но даже и на основе исторических коммуникационных отношений.
Благодаря простому и гибкому администрированию, технология VLAN является
системой выбора для контролирования доступа к системам в зоне управления. С этой
целью все системы, требующие доступа к обслуживанию в зоне управления,
комбинируются и составляют сегмент виртуальной сети (VLAN). Для предотвращения
нежелательной коммуникации между отдельными зонами через виртуальные сети зоны
управления, все системы подогнаны к второму сетевому интерфейсу, который не может
использоваться ни для каких целей, кроме администрирования, и который подогнан к
пакетному фильтру.
Использование технологии VLAN для соединения любых зон, кроме зон
управления, не рекомендуется из соображений безопасности.
7.2.
Сеть, пользователи и внешние сервисы
Сетевой уровень – это связь между системами инфраструктуры компьютерного
центра и внешними сервисами, а также пользователями приложений е-правительства.
Этот уровень охватывает Интернет, Информационную сеть Федеральной Администрации
(IVBV) и VPN-сети, или extranets. Intranets также составляют часть сетевого уровня. Хотя
в последние годы в сфере сетевых технологий наблюдается явная тенденция к
консолидации, но все еще используется хост различных технологий. Однако абстракция
на более высоких уровнях протокола или приложения может сделать систему
взаимооперабельной, так что SAGA не дает конкретных технологических рекомендаций
для сетевого уровня.
С точки зрения инженерного аспекта приложений е-правительства, однако,
безопасная и эффективная коммуникация с Интернетом, IVBV или экстранетами должна
играть важную роль в обеспечении надежного доступа пользователям и внешним
сервисам. При проектировании приложений е-правительства, поэтому, следует
предоставлять необходимые полосы частот на основе оценки предполагаемой сетевой
коммуникации, и должны внедряться механизмы контроля доступа, описываемые в
разделе 7.1.3.
Инициатива BundOnline 2005 предлагает несколько внешних сервисов в форме
базовых и инфраструктурных компонентов, как в Интернете, так и через IVBV.
Дополнительную информацию относительно инфраструктурного компонента IVBV см. в
Приложении А «Базовые модули инициативы BundOnline», раздел А.6, с. 136.
К другим сервисам, таким как базовый компонент е-платежа, можно получить
доступ через веб-сервисные интерфейсы в Интернете. Для этой цели базовый компонент
предоставляет веб-сервисные интерфейсы, необходимые на серверном конце, с одной
стороны, и эталонное внедрение для вызова веб-сервисов соответствующим приложением
е-правительства – с другой. Коммуникация с внешними специальными приложениями
других государственных учреждений или бизнес-структур происходит аналогичным
образом, и доля этих целей могут также применяться интерфейсы микропрограммных
коммуникаций.
Децентрализованные базовые модули, такие как базовые компоненты
«безопасности данных», напротив, реализуются внутри инфраструктуры компьютерного
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
центра отдельных государственных учреждений. В этом случае также должны
соблюдаться правила, уже описанные в разделе 7.1.
8.
Технологическая точка зрения (часть 1): стандарты ИТ архитектуры
В этой главе технические стандарты определены для индивидуальных элементов
архитектурной модели описанной в главе 3. Более того, эта глава также представляет
краткое описание этих технических стандартов. Если нет утвержденного номера версии
стандарта, то эта версия, которая является наиболее стабильной с точки зрения
использования в условиях рынка, хотя данный стандарт может быть не последней версией.
8.1.
Моделирование процесса
Обязательно: Образцы для подражания и календарные графики технологического
процесса.
Образцы для подражания и календарные графики технологического процесса могут
использоваться для определения простых процессов. Все связанные с данным процессом
роли и системы должны быть определены, и этапы процесса должны быть описаны в
форме календарных графиков. Календарные графики должны в широком смысле
ориентированы на DIN 66001: “Information processing, symbols and their use”.
Рекомендовано: Unified Modeling Language (UML Единый язык моделирования)
UML должен использоваться для объектно-ориентированного моделирования для
подготовки и документации больших проектов. Случаи использования – это создание
методом (проб и ошибок) тестирования и координация точных спецификаций. UML,
однако, это сложное приложение, которое требует навыков и когда необходимо,
использования специальных инструментов. С другой стороны, структура данных XML
либо части Java программ могут быть напрямую сгенерировано из подходящих
спецификаций.
8.2. Моделирование данных
8.2.1. Инструменты моделирования
Обязательно: Диаграммы Сущность – связь
Модели функциональных данных для разработки грубых технических концепций
должны быть представлены в форме Диаграммы Сущность – связь
Обязательно: XML Schema Definition (XSD) версия 1.0
Спецификация данных должна быть реализована как XML схема (см. секцию 8.2.2)
Находится на рассмотрении: Unified Modeling Language (UML Единый язык
моделирования)
UML может использоваться для объектно-ориентированного моделирования для
подготовки и документации больших проектов. XML схемы могут быть напрямую
сгенерированы из соответствующих спецификаций.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
8.2.2. Описание данных
Обязательно: Extensible Markup Language (XML)
XML схемы согласно World Wide Web консорциума должны быть сгенерированы с
использованием XML Schema Definition для структурного описания данных.
8.2.3. Трансформация данных
Рекомендовано: Extensible Stylesheet Language Transformation (XSLT) версия 1.0
Если приложения используют разные XML схемы, переход от одного формата к
другому может стать необходимой для цели обмена данными. Изменение этого формата
производится через XSLT язык определенный W3C как часть XSL (Extensible Stylesheet
Language).
8.2.4. Характерные множества
Стандарт, определенный в секции 8.5 «Презентация» применимый к характерным
множествам для использования в обмене данными. Характерное Множество
индивидуальных частей XML схем в дальнейшем в данном контексте может быть
ограничено.
8.3.
Архитектура приложения
Эта секция определяет языки программирования, а также технологии реализации
архитектуры приложения. Первая часть определяет стандарты для промежуточного ПО,
которое является связующим звеном модуля архитектуры е-правительства с особым
акцентом на интеграцию приложений. За этим следует расширение стандартов для охвата
приложений без промежуточного ПО, т.о. чтобы стандарты по промежуточному ПО
могло также быть использовано для упрощения приложений.
Спецификации и рекомендации основаны на принципах дизайна, что
закладываются в реализации плана инициатив BundOnline 2005, т.е. нейтралитет,
способность к взаимодействию и портативность.
Промежуточное ПО – такое как репликация, распределенное управление
транзакциями, персонализация, интернациональность, обмен сообщениями, и т.д. – на
которые ссылаются в текущей версии на ограниченном пространстве.
Отклонения
от технологии должны быть поддержаны (т.е. обязательно,
рекомендованные технологии) лишь в особых случаях, например, в случаях значительных
экономических выгод.
8.3.1. Архитектура приложения с промежуточным ПО
Обязательно: Java 2 Платформа, Enterprise Edition (J2EE) v. 1.4
Развитие и интеграция следующих приложений (интегрированные приложения) на
промежуточном ПО, т.е.
a)
основные компонент,
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
b)
приложения, которые прямо интегрируют основные компоненты либо
библиотеки предназначенные для этих целей, и
c)
Разработанные приложения, для того чтобы повторно использовать
полностью либо часть.
Требуется использование Java 2 Платформа, Enterprise Edition (J2EE) технологий.
J2EE это спецификация, которая определяет несколько программных интерфейсов и
процессы разработки. J2EE в своей полноте составляет архитектуру, которая принимает и
поддерживает большинство аспектов бизнес-критичных приложений. J2EE уде предлагает
модули важные функционально, которые могут быть использованы для разработки
приложений. Версия 1.4 и выше включают так называемые основные библиотеки, и даже
программируемые интерфейсы стандартных приложений (API) и технологии, которые
были классифицированы в SAGA 1.1, т.е. Authentication and Authorization Service (JAAS),
Java API для XML parsing (JAXP) и Java Naming и Directory Interface (JNDI). Все
основный библиотеки должны получить привилегии над альтернативными технологиями.
В сравнении с J2SE, J2EE предлагает так называемые, необязательные библиотеки
несколько API и технологии, включая, например, следующие Java Message Service (JMS)
1.1, J2EE Connector Architecture 1.5, Java Transaction API (JTA) 1.0, JavaMail API 1.3, Java
API for XML Registries (JAXR) 1.0, Java Management Extensions (JMX) 1.2, Enterprise
JavaBeans (EJB) 2.1, Web Services 1.1, Java Server Pages (JSP) 2.0 and Servlet API 2.4. В
следующем (ниже) использование коммуникационных технологий JMS и J2EE Connector
Architecture будет классифицироваться как обязательное. Java EJB и Servlet API
технологии промежуточного ПО от основного для приложений сервера приложений.
Благодаря Java Community Process, больше и больше модулей для приложений
будут увеличивать разнообразие J2EE в скором будущем. Новые модули определены
через так называемые Java Specification Requests (JSR).
Обязательно: Java 2 Platform, Standard Edition (J2SE)
Если приложение не требует полной функциональности J2EE либо на начальной
стадии, либо более поздней, J2EE технологии должны быть использованы индивидуально
как альтернативное решение. Основой для этого является Java 2 Platform, Standard Edition
(J2SE). Индивидуальные технологии технологий должны быть использованы согласно
J2EE Specification 1.4 в порядке создания подходящего миграционного пути для
совместимого J2EE.
Обязательно: Java Database Connectivity (JDBC) версия 3.0
JDBC должно использоваться для доступа к базам данных.
Обязательно: Java Message Service (JMS) 1.1, J2EE Connector Architecture версия 1.5
Либо Java Message Service (JMS) 1.1, либо J2EE Connector Architecture должны
использоваться для интеграции внешних систем.
Рассматривается: Microsoft Windows. NET Framework
.NET Framework – это технология промежуточного ПО, которое было разработано
Microsoft. Системная архитектура .NET включает окружение рабочего цикла для разных
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
языков программирования и окружение разработки. Оно поддерживает большинство web
стандартов (включая SOAP, WSDL, UDDI, XML).
Основные компоненты промежуточного ПО .NET были стандартизированы
национальными организациями. Проекты находятся в процессе разработки, их целью
является реализовать
основные компоненты
промежуточного программного
обеспечения .NET на не Window’ских операционных системах.
Архитектура .NET еще пока не отвечает на требования платформы независящей от
операционной системы. Ожидается что Microsoft будет развивать технологию .NET в
открытый стандарт пока также гарантируется согласованности со стандартами
рассмотренными в SAGA.
8.3.2. Архитектура приложения без применения промежуточного ПО
промежуточного ПО
В дополнение к обсужденным в предыдущей секции стандартам следующая
технология также доступна для простых приложений е-правительства без применения
промежуточного ПО.
Рекомендуется: PHP: Hypertext Preprocessor (PHP) v.4.x
PHP (рекурсивный акроним для PHP: Hypertext Preprocessor) может быть
использован для приложений без требований интеграции, т.о. неделимые автономные
приложения, которые не связаны с одной из базовых компонент, правовых систем либо
других специальных приложений е-правительства. PHP разработано как проект с
открытым кодом Фонда ПО Apache и представляет язык скриптов вложенный в HTML для
разработчиков web приложений.
8.4.
Клиент
Клиент – это ПО на терминальном устройстве, которое использует предложенные
по промежуточному ПО услуги. Ярус Клиент, включающий сайт классического
пользователя со всеми опциями внедренной технологией, должен предложить для
взаимодействия с публичными администрациями доступ к информации через разные
медиа. В Германии, следующие медиа в настоящее время наиболее популярные, т.о. что
оптимальные условия для широкого использования приложений е-правительства будут
существовать, если предложенная информация приспособлена для данных устройств:
a)
b)
c)
Компьютеры (ПК, ноутбуки)
Мобильные телефоны/персональные цифровые помощники
Внешние системы (Такие как системы ERP индустриальных компаний)
Попытки стандартизации для игровой консоли и, особенно, для цифрового
интерактивного телевидения пока не были приведены в единую систему рекомендаций.
Так называемый тонкий клиент является многообещающим устройством в смысле
публичного одобрения. Тонкие клиенты получаются с очень низко профильной техникой
и ПО и требуют сервер для обеспечения как можно большей функциональности.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
8.4.1. Основанный на web/основанный на компьютерах доступ к
информации
Два разных клиента в общем доступны на компьютерной технике для доступа либо
получения информации, т.е. web-браузер и приложения специфического клиента (такие
как Java Clients – также Applet’ы), которые, например, дают возможность прямого доступа
к сервисам Интернета, клиентам e-mail и операционной системе, в зависимости от уровня
привилегированности. Когда же используются активные компоненты, ни одна отличная
от них клиентская технология не может быть использована в SAGA. Использование
Active-X-Controls не позволяется. Когда используется активный контент, должно быть
доступно, если это возможно, параллельное предложение без активного контента.
8.4.1.1.
Web-браузеры
Для того чтобы сделать возможным широкое использование приложений еправительства, web-браузеры должны быть использованы как устройство внешнего
интерфейса, которое должно поддаваться обработке и представляться в формате
презентаций(см. секция 8.5). Следующая клиентская технология, основанная на браузере,
разрешена в следующем контексте:
a)
Использование cookies разрешается при условии, что
1)
если они не постоянны и
2)
сайты домена не включают контент других доменов, которые ???
b)
Рекомендации для http протоколов согласно секции 8.6.3 должны быть
приняты во внимания в данном контексте.
c)
Использование Java скриптов разрешено при условии, что сертификат на
сервер и соединение SSL (см секцию 9.3.1) используются для того, чтобы дать
возможность клиенту идентифицировать его как подлинный и целостный. Секция 8.5.1.5
должен быть принят во внимание при использовании Java скрипт.
d)
Использование Java Applets разрешено, если они подписаны сервером и
следовательно идентифицирована клиентом как надежные и целостные. Производители
Java Applets должны подвергать свой продукт гарантии качества, что предпочтительнее
независимым компаниям, разрабатывающим ПО или должны, наконец, гарантировать
требуемое качество в форме самодекларации. Более подробную информацию по данной
теме можно найти на сайте: http://www.kbst.bund.de/saga-applets.
e)
Точный список поддерживаемых плагинов хранится и публикуется на сайте:
http://www.kbst.bund.de/saga-plugins .
f)
Конфигурация примеров разработанных для обычных типов браузеров,
общественный доступ в сети Интернет предоставлен Британским институтом стандартов.
g)
конфиденциальность данных, содержащихся в формах, должна быть
гарантирована использованием SSL зашифрованных каналов и подходящих сертификатов
серверов.
h)
Установленный документ (указ) на свободу от барьеров остается полностью
приложим для использования разрешенных клиентских приложений.
8.4.1.2.
Клиентские приложения с прямым доступом к Интернет – услугам
Web-браузер – это стандартный клиент для приложений с прямым доступом к webсерверам. Клиентские приложения могут быть использованы, в случае если
функциональность web-браузера обоснованна недостаточно, например, в случаях
сложных бизнес транзакций с системой прямого файлового доступа, либо должно
использоваться легальное ПО. Эти приложения установлены на клиенте и должны быть
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
обновлены по требованию технического прогресса. Обновления доступны на СD-Rom или
как подписанные приложения для загрузки с web-сайта. Использование Java приложений
рекомендуется для этих целей (выгода: независимость платформ).
Клиентские приложения должны отвечать следующим требованиям:
a)
Любые персональные данные и данные, нуждающиеся в защите хранятся в
зашифрованной форме на локальном средстве для данных.
b)
Защищенная трансмиссия данных на сервер поддерживается, например,
согласно транспортным спецификациям OSCI. Ни один протокол кроме определенных в
секции 8.6.1.2 не разрешен для любых других клиент/серверных коммуникаций.
c)
Форматы для обмена пользовательскими данными задокументированные в
SAGA должны поддерживаться другими приложениями.
d)
Фирмы независимых производителей ПО гарантируют качество приложения.
e)
Приложение снабжаются сертификатами ПО, которые подтверждаются в
процессе течении проведения инсталляции.
f)
Кроме того опции загрузки приложения из Интернета, также
распространяются на CD-ROM.
g)
Установленный документ (указ) на свободу от барьеров должен быть принят
во внимание.
8.4.1.3.
E-mail клиент
E-mail клиенты получающие, отправляющие и обрабатывающие e-mail должны,
наконец, гарантировать техническую поддержку для двух следующих стандартов e-mail:
a)
b)
SMTP: для получения и отправления е-почты
MIME: как описание формата е-почты.
Обратите внимание, что взаимосвязь клиентов стандартизирована только в
отношении взаимосвязи с общественными администрациями и/или ограниченна выше. В
отношении использования внешних почтовых серверов, не присоединенных к
федеральным институтам, клиенты не подвергаются каким-либо ограничениям в терминах
используемых стандартов и протоколов.
В исключительных случаях, может быть необходимо предложить электронные
почтовые ящики. Должен быть использован стандарт, описанный в секции 5.6.3.
8.4.2. Доступ к информации через мобильные телефоны / PDA
Протоколы, которые обслуживаются на сервере (см. секцию 8.5.2) в настоящее
время необходимо для того, чтобы использовать предложение по предоставлению связи.
Приложения на терминальных устройствах данного типа пока еще не совсем обычны в
Германии.
8.4.3. Доступ к информации через внешние системы
Коммуникации и взаимодействие между внешними и внутренними системами
должны контролироваться посредством части стандартов, которые определены для
коммуникаций и взаимодействий между внутренними системами. В этом отношении,
XML через SOAL рассматривается как эквивалентное RMI для коммуникаций серверсервер.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
8.5.
Презентация
Основная часть презентации предоставляет клиентам связь с информацией.
Должны быть доступны различные форматы, зависящие от данных приложений. Они
перечислены в следующей секции. Требуется использование открытых форматов обмена,
которые предлагают достаточное количество функций и которые доступны на различных
платформах.
Разрешено предлагать информацию в дополнение, если так согласовано со всеми
участниками, используя как альтернативные – для обязательных и рекомендованных
форматов, форматы, не рассмотренные в рамках SAGA.
8.5.1. Обработка информации – компьютер/ web
8.5.1.1.
Презентация для выведенных из строя
Обязательно: Руководство по информационным технологиям свободным от
барьеров
Для того чтобы сделать Интернет доступным также для людей с физическими и
умственными недостатками, требуется преодоление барьеров для нетрудоспособных
граждан. Для того чтобы гарантировать такой тип свободы от барьеров необходимо
придерживаться следующего «Руководства на создание свободных от барьеров ИТ,
соответствующих
закону
о
равных
возможностях
для
нетрудоспособных
граждан(руководство по свободным от барьеров ИТ-BITV)» (Ordinance on the creation of
barrier-free information technology pursuant to the law on equal opportunities for the disabled).
Установленный документ реализует секцию 11 Акта о равных возможностях для граждан
с физическими и умственными недостатками (Equal Opportunities for Individuals with
Disabilities Act), в частности, рассматривается Руководства по доступности web контента
(Web Content Accessibility Guidelines) W3C версия 1.0. Касательно темы свободы от
барьеров см. секцию 4.1.5.3 стр. 42.
8.5.1.2.
Форматы обмена данными для гипертекста
Обязательно: Hypertext Markup Language (HTML) версия 3.2
Формат HTML 3.2 должен поддерживаться для того чтобы гарантировать более
ранних поколений браузеров.
Рекомендуется: Hypertext Markup Language (HTML)версия 4.1
Браузеры, которые уже широко используются сегодня для поддержки
предшественников формата HTML версии 3.2. W3С рекомендует с одной стороны чтобы
авторы использовали HTML версии 4.01, и те браузеры, которые поддерживают HTML
4.01 и с другой стороны сами являются совместимыми с более ранними версиями. HTML
4.01 также необходим для технической реализации безбарьерного доступа согласно
Руководству по доступности web контента (Web Content Accessibility Guidelines) 1.0.
Несмотря на это, однако, может так случиться, что браузеры не польностью
поддерживают
HTML 4.01. Поэтому должна быть гарантирована совместимость с
HTML 3.2. Это значит, что а) информация может быть представлена полностью и б)
функции могут быть использования полностью, но что определенный дизайн и разбивка
ограничений для презентаций на HTML листе не могут быть обойдены.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Рассматриваются: Extensible Hypertext Markup Language (XHTML) версия 1.0
XHTML 1.0 определяет HTML 4.1 как XML – приложение. XHTML 1.0 должен
быть использован, когда разрабатывается и запускается новое поколение браузеров.
Приложения должны гарантировать совместимость с HTML 3.2..
8.5.1.3.
Таблица стилей
Таблица стилей может быть использована для того чтобы гарантировать единое
представление информации предложенной браузерами разных типов. Таблицы стилей это
образцы форматирования для данных всех типов, которые описывают как разметка,
которая должна быть представлена на языке, согласующемся с SGML. В зависимости от
приложения, могут быть использованы обе или одна из следующих, введенных W3C,
таблиц стилей:
Рекомендуется: Cascading StyleSheets Language Level 2 (CSS2)
Cascading StyleSheets Language Level 2 (CSS2) должны использоваться для
разработки HTML страниц.
Рекомендуется: Extensible StyleSheets Language (XSL) версия 1.0
Extensible StyleSheets Language (XSL) версия 1.0 необходимо для трансформации и
представления XML документов в формате HTML.
8.5.1.4.
Множества типов
Обязательно: ISO 10646-1:2000/Unicode v.3.0 UTF – 8
Для того чтобы обеспечить достаточное количество типов для разных переменных,
чисел и широко используемых символов, множество типов, используемых для документов
в формате HTML ISO 10646-1:2000/Unicode v3.0 UTF-8 кодировочной версии.
Рекомендуется: ISO 10646-1:2000/Unicode v.3.0 UTF – 16
Кодировка UTF-16 должна применяться для документов на греческом, либо на
других не-западных языках европейских языках.
Рекомендуется: ISO 8859-1
Множество типов ISO 8859-1 еще используются и могут использоваться в
дальнейшем.
Рекомендуется: ISO 8859-15
Кодирование согласно ISO 8859-15 еще используется и будет разрешено с данной
точки зрения.
8.5.1.5.
Статический и динамический, пассивный и активный контенты.
Статический контент - это файлы, которые сгенерированы web-сервером в
процессе прогонки, но которые типично импортированы из и применены файловой
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
системой. Динамический контент- это HTML файлы, которые сгенерированы и посланы
на сервер в процессе прогонки – например, в ответ на запросы базы данных.
Пассивный контент – это HTML файлы, которые не содержат никаких
программных кодов или компьютерных программ, которые содержатся на web сайтах
(например, JavaScript) либо автоматически перегружен, когда
просматривается
программа (например, Java Applets, ActiveX Controls или флэш-анимация) и которая
осуществленная на клиенте (браузером или операционной системой). Про использовании
активного контента должны быть приняты во внимание ограничения рассмотренные в
секции 8.4.
Обязательно: Hypertext Markup Language (HTML)
Информация, предоставляемая в виде HTML страниц должна быть использована
на основе формата определенного в секции 8.5.1.2. Поддержка активных контентов и
плагинов может считаться доказанным для пространства (рамок) определенных в секции
8.1.
Обязательно: ECMA-262-ECMAScript Language Specification
А также Javascript используется в HTML страницах согласно секции 8.4.1.1 все это
должно выполняться со спецификацией ECMA-262.
Рекомендуется: Servlets and Java Server Pages (JSP) или Extensible Stylesheet
Language (XSL)
Servlets и JSP или Servlets и XSL должны быть использованы для динамического
поколения HTML страниц основанных на сервере.
8.5.1.6.
Типы файлов и идентификация для текстовых документов
Для текстовых документов должны использоваться разные типы файлов в
зависимости от данного приложения:
Обязательно: Текст (.txt)
Простые текстовые документы, позволяющие редактирование, заменены на
широко используемый формат (.txt) для того чтобы гарантировать большую возможность
прочтения. Набор знаков должны быть использованы согласно стандарту ISO 8859-1 и
включать значения ASCII и смешанные гласные.
Обязательно: Hypertext Markup Language (HTML)
Гипертекстовые документы должны быть использованы в html формате как (.html)
файлы (см. секция 8.5.1.2).
Обязательно: Portable Document Format (PDF) версия 1.3
Текстовый документ не поддающийся редактированию должен быть доступен в
Adobe Portable Document Format как (.pdf) файл. PDF версии 1.3 используется Acrobat
software версии 4 и выше.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Рекомендуется: Extensible Markup Language (XML)
XML может также быть использован для описания документов и предлагает более
широкий выбор шаблонов и опций, чем HTML.
Рассматривается: Portable Document Format (PDF) версия 1.4
Для поддержки форм и документов свободных от барьеров, можно использовать
версию 1.4 Portable Document Format от Adobe как (.pdf), который пока не очень широко
используется. PDF версии 1.4 поддерживается программный продуктом Acrobat версии 5
и выше. Если этот формат используется для форм рекомендации модуля «Безопасное
присутствие в Интернете» руководства по е-правительству должен рассматриваться
относительно активного контента (см. секцию 8.5.1.5).
Обязательно: Multipurpose Internet Mail Extensions (MIME)
Multipurpose Internet Mail Extensions (MIME) формат должен использоваться для
стандартизации определения формата файла либо какой-либо его части. Это дает
возможность e-mail клиенту или web-браузеру точно определить тип; см. RFC 2045 и RFC
2049.
8.5.1.7.
Типы файлов для крупномасштабных таблиц
Для крупномасштабных таблиц должны использоваться разные типы файлов в
зависимости от изменчивости требований к документам.
Обязательно: Comma Separated Value (CSV)
Разграниченные, разделенные запятой крупномасштабные таблицы должны
храниться и обмениваться как (.csv) файлы.
Обязательно: Portable Document Format (PDF) версия 1.3
Аналогично секции 8.5.1.6
Рассматриваются: Portable Document Format (PDF) версия 1.4
Аналогично секции 8.5.1.6
8.5.1.8.
Типы файлов для презентации
Презентации должны быть использоваться в разных форматах в зависимости от
изменчивости требований к документам.
Обязательно: Hypertext Markup Language (HTML)
Презентации, которые могут быть редактированы, должны быть заменены как
гипертекстовые документы в формате как (.html) файлы (см. сектор 8.5.1.2 «Обмен
форматами для гипертекста»).
Обязательно: Portable Document Format (PDF) версия 1.3
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Аналогично секции 8.5.1.6
Рассматриваются: Portable Document Format (PDF) версия 1.4
Аналогично секции 8.5.1.6
8.5.1.9.
Формат обмена для графиков
Обязательно: Graphics Interchange Format (GIF)
В виду его широкого применения, Graphics Interchange Format (.GIF) должен
использоваться для обмена графиками и диаграммами, с (.GIF) графическими файлами
сжатыми с глубиной цветов в 256 цветов (8 бит на пиксель).
Обязательно: Joint Photographic Expert Group (JPEG)
Joint Photographic Expert Group (.JPEG) формат должен быть для обмена
фотографиями. Этот формат поддерживает изменения коэффициента сжатия и
определение плотности, т.о. что способствует компромиссу между размером файла,
качеством и применением. Поддерживается 16,7 миллионов цветов (24-бита информации).
Рекомендуется: Portable Network Graphics (PNG)
Portable Network Graphics (.PNG) графический формат должен быть применен при
необходимости. (.PNG) формат является бесплатным продуктом. Он поддерживает 16
миллионов цветов, прозрачность, сжатие без потерь, увеличение демонстрации графиков
(начиная с крупных структур пока файлы полностью переданы) и идентификация
поврежденных файлов.
(.PNG) становится обязательным вместо (.gif) как только будут разработаны новые
браузеры пятого поколения.
Рекомендуется: Tagget Image File Format (TIFF)
Tagget Image File Format (.TIFF) должны быть применены для графической
информации, что не допускает потери информации. (.TIFF) это файловый формат для
побитового отображения с разными форматирующими опциями, которые позволяют
приложению обрабатывать либо игнорировать часть изображения.
Рекомендуется: Enhanced Compressed Wavelet (ECW)
Enhanced Compressed Wavelet (.ECW) формат побитового отображения должен
быть использован при необходимости максимального сжатия.
8.5.1.10.
Формат обмена для графической информации (табличные данные,
векторные данные)
Предоставление графической информации через Интернет («киоск гео-данных») и
ее картографическая презентация (WebGIS) в Интернет становится все более популярной.
Презентация графической информации в форме тематических карт через Интернет –
порталы может быть осуществлена через табличные данные либо как векторная графика
на уровне презентации. Векторная графика описывает изображение как
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
последовательность геометрических объектов. Эти объекты (например, линия, круг,
сплайн, верхний слой (?)) имеют следующие свойства: положение, цвет и классификация.
Рекомендуется: Geography Markup Language (GML)
GML (Geography Markup Language) это язык разметки для транспортировки и
хранения
географической
информации,
рассматривает
географические
и
негеографические свойства.
GML был определен Open GIS Consortium (OGC). GML не содержит информации
касательно презентации на экране либо на карте. Геометрии представлены простыми
чертами, которые также определены OGS.
Пока версия 2.0, спецификация основана на XML Schema Definition (XSD)
предпочтительнее, чем на document type definition (определении типа документа (DTD)).
8.5.1.11.
Формат обмена для аудио и видео файлов
Обязательно: MPEG – 1 Layer 3 (MP3)
Обычный (.mp3) формат должен применяться для обмена аудио
последовательностями, с (.mp3) значением MPEG – 1 Layer 3 (MPEG=Motion Picture
Experts Group). (.mp3) это метод, который позволяет экстремально высокий процент
сжатия для аудио и видео данных с максимальным качеством. Подходящий плагин
позволяет браузеру «играть» такие файлы.
Обязательно: Quicktime (.qt, .mov)
Обычный Quicktime формат должен быть применен для обмена видео
последовательностями. Подходящий плагин дает возможность браузеру «играть» такие
файлы.
Рассматривается: Windows Media Video (.wmv)
Качество Windows Media Video (.wmv) формата лучше, чем качество Quicktime
формат. Однако, плееры для разных операционных систем в формате (.wmv) пока не
доступны в таком количестве как в случае с Quicktime. WMV применяется лишь в случае
однородной группы, чья операционная система известна и поддерживается плеерами для
WMV формата.
8.5.1.12.
Формат обмена для аудио и видео потоков
В отличие от «нормальной» аудио и видео последовательности, аудио и видео
потоков предлагает формат, который позволяет играть даже во время трансмиссии. Это
делает возможным одновременный просмотр и трансмиссию видео, в то время как
«нормальные» аудио и видео файлы должны быть полностью перенесены и только после
этого могут быть запущены. Эта область иногда характеризуется легким непониманием
смеси поставщиков, продуктов, вместилища и форматов контента. Пока SAGA
намеревается рекомендовать продукты, рекомендации будут даны только для формата
вместилища.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Одно из важных требований, это то, что рекомендации должны быть совместимы –
в максимально возможной степени – с обычными поточными сервер и клиентскими
продуктами. В следствии того, что данная область является полем для сильной
конкуренции последние несколько лет, разные продукты, в настоящее время, хорошо
совместимы в смысле поддерживаемых форматов.
Обязательно: Hypertext Transfer Protocol (HTTP) версия 1.1
Для того чтобы достичь так много граждан, как можно, избранный серверный
продукт должен в любом случае возможность транспортировать потоковые данные через
HTTP.
Обязательно: Quicktime (.qt, .mov)
Для того чтобы достичь максимально возможной степени совместимости поточной
связи с обычно используемыми браузерами, аудио и видео клиентами, а также плагинами,
использование Quicktime формата рекомендуется т.к. он в настоящее время
поддерживается всеми обычными продуктами.
Рассматривается: Ogg
Ogg – это формат контейнера вне зависимости от производителя для потоков аудио
(Ogg Vorbis) и видео (Ogg Theora, Ogg Tarkin) информации, которые в настоящее время
развито под Open Source. Лидирующий производитель streaming серверов уже объявили,
что они в ближайшем будущем будут поддерживать этот формат. Ожидается, что этот
формат будет все более и более популярным в ближайшем будущем.
Рассматривается: Windows Media Video (.wmv)
Качество Windows Media Video (.wmv) формата лучше, чем Quicktime формат.
Однако, плееры и streaming серверы для разных операционных систем еще пока не
доступны для Windows Media Video в том объеме как в случае с Quicktime. В данном
формате, некоторые GIF изображения хранятся в файле, с возможностью определять их
последовательность, показывает время и количество копий.
8.5.1.13.
Анимация
Обязательно: Анимированный GIF
Анимация означает движение графики продемонстрированное на сайте.
Анимированный GIF, один из видов формата gif – графики, должен в данном случае
получить предпочтение. В данном формате, несколько отдельных GIF – изображений
хранятся в файле, с возможностью определения их последовательности, показ времени и
число повторений.
8.5.1.14.
Сжатие данных
Система сжатия должна быть использована, для того чтобы иметь возможность
обмена файлами большего объема и загрузка минимальной сети.
Обязательно: ZIP версия 2.0
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Данные подвергающиеся сжатию должны быть заменены на (.zip) файлы
международного ZIP формата версии 2.0.
Рекомендуется: GZIP версии 4.3
Альтернативой является GZIP формат, версии 4.3, с
определено в RFC 1952.
(.gz) расширением как
8.5.2. Обработка информации – мобильный телефон/ PDA
В ситуации, когда информационное предложения для мобильных телефонов и PDA
находится на стадии развития, предпочтение отдается SMS системе, т.к. он широко
распространен среди граждан. Представление web-сайтов для мобильной связи пока не
достаточно используется в Германии.
Обязательно: Short Message Services (SMS)
Short Message Services реализовано на основе спецификаций полученных из SMS
Форума. SMS форум –это международный форум большей части IT компаний.
Рассматривает: Wireless Markup Language (WML) версия 1.х
Wireless
Markup
Language
был
разработан
для
применения
в
узкоспециализированном окружения, в частности, беспроводной связи, он является
языком разметки для WAP. Все провайдеры беспроводной связи в Германии
поддерживают WML версии 1.х.
Очень удачная i-услуга японской коммуникационной компании NTT DoCoMo была
недавно запущена в Германии под лицензией для мобильных телефонов. В соответствии с
лицензией, терминальные устройства, поставленные в Германию с системами дуалбраузером, которые поддерживаются обоими частным iHTML форматом и WML
форматом версии 1.х, который обычно используется в Европе, т.о. что WML версии 1.х
встречается с SAGA требованиями.
Рассматривается: Wireless Application Protocol (WAP) версия 1.х
Wireless Application Protocol (WAP) версии 1.х это спецификация для развития
приложений, которые используют сети беспроводной связи. Его главное применение это
мобильная связь.
Рассматривается: Extensible Hypertext Markup Language (XHTML) Basic
XHTML Basic это стандарт представления HTML страниц преобразованными в
XML для приложений, которые не поддерживают полную функциональность презентации
HTML (такие как мобильный телефон или PDA). Подмножество HTML Basic в настоящее
время под определением для разных терминальных устройств.
Такие как WML версии 1.0, WML версии 2.0 опять основаны на XML. Однако,
подмножество XHTML Mobile Profile Specification, которая, в свою очередь, является
подмножеством XHTML Basic.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
8.5.3. Обработка информации – внешние системы
См. секцию 8.2 «Моделирование данных», 8.3 «Архитектура приложения», 8.6
«Связь», и 8.7 «Соединение с задней частью». Однако, только подмножество стандартов
упомянутых в области промежуточного ПО важных для связи с внешними системами.
XML и технология web услуг находятся в центре связей с внешними системами.
Существующие интерфейсы основанные на стандартах OSI мало помалу перенесены.
8.6.
Коммуникации
В части «Коммуникации» установлено различие между
промежуточным ПО и протоколами сети, а также сервисами директории.
приложением,
8.6.1. Протоколы промежуточного ПО
В случае с промежуточным ПО, установлены различия между сервером
приложений, которые связаны в рамках администрации (см. секцию 8.6.1.1) и
клиентскими приложениями вне администрации, которые взаимодействуют с сервером
администрирования (см. секцию 8.6.1.2).
8.6.1.1.
Связь сервер-сервер в рамках администрации
Обязательно: Remote Method Invocation (RMI)
Remote Method Invocation (RMI) очень подходит для связей между приложениями
или компонентами приложений, которые основаны на архитектуре J2EE, если требования
к ограничениям протокола позволяют это. Через RMI, объект на Java Virtual Machine (VM)
может призвать методы объектов, которые выполняются на других Java VM.
Обязательно: Simple Object Access Protocol (SOAP) версия 1.1
SOAP может быть использован для коммуникации между приложениями и
компонентами приложений, которые основаны на архитектуре J2EE, если требования к
ограничениям протокола позволяют это. SOAP особенно подходят для коммуникации
между серверами не основанными на архитектуре J2EE. SOAP может быть использован
для изменения структурированными как XML объектов между приложениями или
компонентами приложения через Интернет протокол (например, через HTTP).
Обязательно: Web Services Description Language (WSDL) версия 1.1
Web Services Description Language (WSDL) должен быть использован с целью
определения услуг. WSDL - это стандартизированный язык, который описывает webуслуги таким способом, что они могут быть использованы другими приложениями без
необходимости знать детали дальнейшей реализации или использовать тот же язык
программирования.
Обязательно: XML Schema Definition (XSD) версии 1.0
Передача элементов данных это детальное изложение через XML Schema.
Рекомендуется: Java Remote Method Invocation over Internet – ORB Protocol (RMIIIOP)
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
RMI-IIOP это неотъемлемая часть J2EE. J2EE приложения и компоненты
приложений могут быть соединены через RMI-IIOP с CORBA компонентами, если
соответствующие Object Request Brokers доступны подходящих серверах приложений.
8.6.1.2.
Связь клиент-сервер
Web-услуги должны быть использованы для доступа клиентским приложением
через Интернет к сервис - приложениям предлагаемым администрацией.
Обеспечивая уровень web-услуг для существующих серверных приложений, это
дает возможность клиентским системам привлекать функции приложений через Hypertext
Transfer Protocol (HTTP). Web-услуга это компонент ПО, который использует SOAP для
того чтобы взаимодействовать с другими компонентами через стандартный протокол
HTTP. XML служит для самого содержания приложения. XML был уже описан в секции
8.2 «Моделирование данных» как универсальный и основной стандарт для обмена
данными между всеми информационными системами имеющими отношение к целям
администрирования.
Web Service Interoperability Organization определяет контур существующих
стандартов для того чтобы способствовать объединению требуемых стандартов.
Профиль использования – это WS-I-Basic и включает XML Schema версии 1.0, SOAP
версии 1.1, WSDL версии 1.1 и UDDI версии 1.0.
Обязательно: Simple Object Access Protocol (SOAP) версия 1.1
SOAP может быть использован для изменения структурированных данных как
XML объектов через Интернет протокол (например, через HTTP).
Обязательно: Web Services Description Language (WSDL) версия 1.1
Web Services Description Language (WSDL) должен быть использован с целью
определения услуг. WSDL - это стандартизированный язык, который описывает webуслуги таким способом, что они могут быть использованы другими приложениями без
необходимости знать детали дальнейшей реализации или использовать тот же язык
программирования.
Обязательно: XML Schema Definition (XSD) версии 1.0
Передача элементов данных это детальное изложение через XML Schema.
Рассматривается: Universal Description, Discovery and Integration (UDDI) версия 1.0
UDDI (Universal Description, Discovery and Integration) проект, в его последней
версии 2.0, Это инициатива основанной на XML технологии, которой следуют компании
из всех ветвей производства нацеленные на публикации, структурированный менеджмент
и предложение пользователям web-услуг. UDDI основан на стандарты изданные W3C и
Internet Engineering Task Force (IETF), таких как XML, HTML, DNS и SOAP.
8.6.2. Сетевые протоколы
Обязательно: Internet Protocol (IP) версии 4
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
ИТ окружение федеральной администрации в настоящее время использует IP
версии 4 (RFC 0791, RFC 1700) в союзе с TCP (Transmission Control Protocol, RFC 793) и
UDP (User Diagram Protocol, RFC 768).
Рассматривается: Internet Protocol (IP) версии 6
IP версии 6 это следующая версия IP протокола, который пока еще не очень
широко используется. Одно из изменений предшествовавшее текущей версии 4 это
раширение IP адреса до 128 бит для того чтобы позволить адресование мульти-вложенных
и мобильных систем, которые будут основаны на IP в будущем.
IP версии 6 включает IP – протокол безопасности, который главным образом
использоваться в области VPN (Virtual Private Network (Виртуальная частная сеть)) и
которая может быть также использована не зависимо от IP версии 6. Для дальнейшей
информации по этому вопросу, см. web-сайт рабочей группы «Security on the Internet» или
Германского федерального офиса по Информационной безопасности.
Когда должны быть представлены компоненты новой системы, эти компоненты
должны поддерживать и IP 4 и IP 6 для того чтобы суметь в будущем осуществить
миграцию.
Обязательно: Domain Name Services (DNS)
Domain Name Services (DNS, RFC 1034, RFC 1035, RFC 1591) стал стандартом
функциональности Интернет с середины 80-х 20 века. DNS ссылается на иерархическое
имя серверных услуг в центральной точке Интернета. Место где вводится имя сервера
преобразовано в подходящий IP адрес.
8.6.3. Протоколы приложения
Секция 6.4.2 связана с интеграцией компонентами инфраструктуры связанной с
безопасностью (таких как предписывающие услуги для сертификации, списков
отзывов(аннулирования), и т.д. ).
Обязательно: File Transfer Protocol (FTP)
File Transfer Protocol (FTP, RFC 959, RFC 1123, RFC 2228, RFC 2640) принят как
стандартный протокол перемещения файлов. FTP одна из самых старых Интернет – услуг.
FTP
может
распределено
использовать
файлы,
предлагает
пользователям
стандартизированный пользовательский интерфейс для разных типов файловых систем,
эффективно и надежно перемещает данные. FTP это обычно более быстрый протокол
нежели HTTP, в случаях, когда необходимо загрузить большие файлы.
Обязательно: Hypertext Transfer Protocol (HTTP) версии 1.1
HTTP 1.1 (RFC 2616) должен быть использован для связи между клиентом и webсервером. Однако. Web-серверы должны также поддерживать HTTP 1.0 (RFC 1945) в
дополнение к версии 1.1. Стандарт HTTP State Management Mechanism (RFC 2965)
Должны быть адаптированы вместе с HTTP Session Management и cookies.
Обязательно: Simple Mail Transfer Protocol (SMTP) / Multipurpose Internet Mail
Extensions (MIME)
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Протоколы E-mail в соответствии с спецификациями SMTP/ MIME для обмена
сообщениями (RFC 821, RFC 822, RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049)
требуются для пересылки э-почты. Прикрепления к э-почте должны быть привязаны к
форматам файла определенным в секции 8.5.
Обязательно: Post Office Protocol (POP 3) / Internet Message Access Protocol (IMAP)
В исключительных случаях, может быть необходимо предложить электронные
почтовые ящики. POP 3, либо IMAP должны использоваться как обычно используемые
для подобных случаев стандарты.
8.6.4. Предписывающие услуги
Обязательно: Lightweighted Directory Access Protocol (LDAP) версии 3
LDAP версии 3 (RFC 2251) это основанный на Х.500 Интернет протокол, который
оптимизирован в отношении к иерархически структурированной информации и которые
используются для доступа к предписывающих услуг.
Рассматривается: Universal Distinction, Discovery и Integration (UDDI) версии 1.0
UDDI проект это инициатива технологии основанной на XML, которой следуют
компании из всех ветвей производства нацеленные на публикации, структурированный
менеджмент и предложение пользователям web-услуг. UDDI основан на стандарты
изданные W3C и Internet Engineering Task Force (IETF), таких как XML, HTML, DNS и
SOAP.
Рассматриваются: Directory Services Markup Language (DSML) версии 2
DSML - это определение в XML, которое дает доступ к предписывающим услугам.
Это позволяет применять несколько директорий в один момент.
8.7.
Соединение с задней частью
Германская администрация использует несколько наследных систем, которые
наиболее вероятно останутся в эксплуатации и в будущем (такие как ERP, основной
транзакционный процесс, система баз данных и другие наследные приложения). В
зависимости от режима работы, эти системы могут быть разделены на три категории
следующим образом:
a)
Безопасные транзакции, обрабатываемые конечными пользователями через
существующие системы диалога
b)
Асинхронные данные групповой обработки (тотальная обработка)
c)
Связь Программа-программе на основе соответствующих протоколов
Две опции в общем доступны для наследственных интегрирующих систем:
a)
Прямая интеграция через так называемые «наследственные интерфейсы»
b)
Интеграция через отдельные интеграционные слои, с модульной
инкапсуляцией реального доступа к наследственным системам.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Концепции детального решения должны быть оценены и сравнены с точки зрения
целей, которые должны быть достигнуты, доступного времени и бюджета, а также
функций, которые должны поддерживаться в процессе интеграции наследной системы.
Следующие секции рассматривают разные концепции
соответствуют трем упомянутым выше режимам работы.
решений,
которые
8.7.1. Диалоговые системы
Интеграция наследственных систем в решения е-правительства Германской
администрации возможно с или без интеграционного слоя.
a) с интеграционным слоем
Новый пользовательский интерфейс разработан для презентаций на браузере.
Обработка наследственных данных будет т.о иметь место на отдельном интеграционном
слое.
b) Без интеграционного слоя
Соответствующий продукт перемещается с существующего диалога
пользовательский интерфейс, который может, т.о. быть осуществляться в браузере.
в
8.7.2. Групповая обработка
Много больших коммуникационных систем обрабатывают свои данные
групповыми процессами, в частности, когда должны обработаться большие объемы
информации. Данные доставляются большими объемами либо передаются через file
transfer.
Рекомендуется: Extensible Markup Language (XML)
Этот метод, при котором данные передаются через XML документы будет
поддерживаться в будущем; см. секцию «Моделирование данных». Это открывает новые
опции и увеличивает гибкость интерфейсов.
8.7.3. Связь Программа к программе
Федеральной администрацией широко используется определенные интерфейсы.
Эти интерфейсы должны применяться и модернизироваться.
Рекомендуется: Extensible Markup Language (XML)
Информационный обмен через XML документы становится установленной
процедурой, когда это нужно адаптировать обработку интерфейсов, которые пока
основываются на соответствующих протоколах для передовых технологий. Сегодня,
производители предлагают необходимые интерфейсы для конвертирования данных в
XML формат, т.о. что требования к разработке снижаются и разработка отдельной
соединительной функциональности в дальнейшем не нужна.
Рекомендуется: Java Message Service (JMS) версии 1.1, J2EE Connector Architecture
версии 1.5
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Для того чтобы гарантировать мягкую интеграцию в J2EE платформу,
рекомендовано для интеграции использовать Java Message Service и J2EE Connector
Architecture.
Рекомендовано: Web – услуги
Web-услуги средство выбора для передачи данных.
9.
Технологический аспект (часть II): стандарты безопасности данных
Обеспечение безопасности данных – один из главных факторов успешного
внедрения сервисов в рамках проекта BundOnline 2005. Безопасность данных
представляет и поддерживает доверительное и безопасное взаимодействие между
гражданами, государственными учреждениями и бизнесом.
Архитектурная модель е-правительства (см. главу 3) определяет безопасность
данных как вездесущий компонент, который может поддерживаться по мере
необходимости – подходящими процессами, методами и форматами данных в каждом
элементе и каждой части комплекта. Технические средства должны применяться так,
чтобы создавалось доверие между теми, кто сообщается друг с другом, чтобы
обеспечивалась исходная защита, и чтобы выполнялись классические задачи защиты.
Поскольку релевантность мер безопасности в последние годы колоссально
увеличилась в связи с растущим использованием Интернета, то и работа по
стандартизации в этой области также возросла. Результатом стал комплекс стандартов
безопасности, директив и рекомендаций.
В данной главе представляются соответствующие стандарты безопасности и
рекомендации для услуг е-правительства.
9.1.
Цели и принципы безопасности данных
Стандарты безопасности данных, представляемые здесь, помогают определить,
требуется ли защита той или иной услуге. Только если выявляется потребность в защите,
будет необходимо принять защитные меры.
9.1.1. Цели защиты
Цели защиты в общем виде определяют интересы безопасности партнеров по
коммуникации:
a)
Конфиденциальность – защита против разглашения несанкционированным
сторонам: никакие данные не предоставляются и не раскрываются несанкционированным
лицам, организациям или процессам.
b)
Целостность – защита против манипулирования: несанкционированное
изменение или уничтожение данных невозможно.
c)
Аутентичность – защита против фальсификации идентичности /
происхождения
d)
Доступность – защита против сбоев IT-систем: к свойствам и /или ресурсу
организации может быть доступ, и они могут использоваться, когда к этому
предпринимает попытку санкционированная организация. Кодирование информации
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
(криптография) – важный инструмент сохранения конфиденциальности, целостности и
аутентичности.
Высокая степень доступности достигается
распространению и толерантности к ошибкам.
благодаря
множественности,
9.1.2. Требования защиты
Требования защиты должны определяться для всех и всяческих IT-приложений.
Эти требования касаются потенциального ущерба, причиненного повреждением данного
IT-приложения.
Пособие по исходной IT-защите (раздел 2.2 Определение потребности в защите –
см. http://www.it-grundschutzhandbuch,de/) разъясняет процедуру определения потребности
в защите. Пособие по е-правительству (модуль: План по е-правительству по фазам – фаза
3 «Анализ» - см.http://www.e-government-handbuch.de/) разбивает эти требования на
четыре категории на базе Пособия по исходной IT-защите:
Категория
«Ничего»
«От
основного
умеренного»
«Высокий»
«Очень высокий»
Эффект ущерба
Не требуется никакая конкретная защита, т.к. не
ожидается никакого воздействия убытка или ущерба.
до Влияние любого убытка или ущерба ограниченно.
Влияние любого убытка или ущерба может быть
значительным.
Влияние любого убытка или ущерба может приобрести
катастрофические размеры, что может угрожать самому
существованию учреждения / компании.
Рис. 9-1: Категории требований защиты
Категория требований защиты может присваиваться каждой защитной цели с тем,
чтобы оценить приложения с точки зрения безопасности. Пособие по е-правительству
(модуль: план е-правительства по фазам – фаза 3 «Анализ») дает примеры того, как
определить требования по защите.
Один из факторов, которые следует особо учитывать при определении требований
к защите, - обрабатываются ли личные данные с целью обеспечить, чтобы соблюдались
законы о защите данных. SAGA не объясняет никаких мер по защите данных. Пособие по
е-правительству (модуль: е-правительство, согласующееся с защитой данных) содержит
информацию по защите данных с учетом рамок компетенции, насущных проблем и
рекомендуемых действий.
Рис. 9-2: Структурная модель стандартов безопасности
9.1.3. Структурная модель безопасности данных
Чтобы сделать стандарты безопасности более легкими для понимания и
применения, архитектурная модель е-правительства, описанная в главе 3, была повышена
до структурной модели по безопасности (см. рис. 9-2)
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Структурная модель не является моделью уровней, она иллюстрирует различные
спецификационные процессы для достижения желаемых целей безопасности. Таким
способом она создает понимание комплексной природы IT-безопасности.
Стандарт безопасности данных обычно охватывает больше, чем один структурный
уровень, поэтому классификация цели не проводится. Однако любой стандарт может
рассматриваться с точки зрения отдельных структурных уровней.
Структурная модель и упомянутые стандарты безопасности данных не
освобождают соответствующих экспертов от обязанности выполнить тщательный анализ
каждого данного приложения c учетом соответствия законам и требованиям правовой
защиты и соблюдать уровень безопасности во всех случаях и во всех процессах цепочки
взаимодействия. Следует провести анализ рисков по приложениям, выделить требования
по защите и разработать концепцию безопасности.
Цели защиты, требования по защите и приложения определяют задачи мер по
безопасности.
9.2.
Стандарты для концепции безопасности
Законы и решения федерального правительства должны рассматриваться как
обязательные к исполнению. Эти законы и решения дополняются рекомендациями и
директивами по IT-безопасности.
Для определения требований по защите должны применяться рекомендации и
указания Федерального Офиса Германии по информационной безопасности (BSI) и
Комитета сотрудничества по автоматизированной обработке данных для федерального
правительства, федерально-земельного правительства и сектора муниципальной
администрации (KoopA ADV). Если обнаруживается, что то или иное приложение или
компонент нуждается в защите, то соблюдение этих рекомендаций и указаний становится
обязательным.
Обязательно: BSI, Пособие по исходной IT-защите
Требуется применение Пособия по исходной IT-защите BSI (пособие по
подготовке концепций IT-безопасности по обычным требованиям безопасности) и
реализация стандартных мер безопасности, рассматриваемых в этом документе. Пособие
по исходной IT-защите предлагает простой и удобный способ реализации концепций ITбезопасности. Структура Пособия поддерживает компонентно-ориентированный подход.
Рекомендуется:
Комитет сотрудничества по автоматизированной обработке
данных для федерального правительства, федеральноземельного
правительства
и
сектора
муниципальной
администрации (KoopA ADV), Руководство по внедрению
электронной подписи и шифрования в администрацию
Руководство по внедрению электронной подписи и шифрования в администрацию,
выпущенное Комитетом сотрудничества по автоматизированной обработке данных для
федерального правительства, федерально-земельного правительства и сектора
муниципальной администрации (KoopA ADV), предназначено для облегчения разрешения
криптографических проблем по отобранным проектам в государственной администрации
и поэтому оно представляет собой действенную помощь государственным учреждениям.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Типовые проблемы и задачи определены в форме сценариев, для которых выделяются и
описываются потенциальные решения.
Рекомендуется:
BSI, пособие по е-правительству
Пособие по е-правительству было создано BSI для поддержки инициативы
BundOnline 2005. Пособие содержит организационные и технические рекомендации по
применению IT в приложениях е-правительства. Рекомендации, касающиеся безопасности,
являются одной из центральных черт этого пособия.
9.3.
Стандарты для конкретных приложений
Для того, чтобы назначать стандарты безопасности реалистичнее, сформулированы
часто встречающиеся приложения с точки зрения безопасности (см. Рис. 9-3).
9.3.1. Безопасная передача веб-содержания и аутентичность вебсервера
Когда клиент сообщается с веб-сервером государственного органа, должны быть
приняты меры для обеспечения того, что коммуникация действительно происходит с этим
сервером (аутентичность веб-сервера). Поиск информации, т.е. передача веб-содержания,
по которому требуется целостность и / или конфиденциальность, во время коммуникации
через Интернет должен производиться безопасным образом.
Обязательно:
Слой безопасных гнезд (SSL) / Безопасность транспортного слоя (TLS)
Протокол SSL – это криптографический протокол, обеспечивающий целостность,
конфиденциальность и аутентичность во всемирной сети. SSL был разработан в развитие
протокола TLS.
Информация
Безопасная передача
веб-содержания
(целостность и
конфиденциальность)
Аутентичность вебсервера
Защита emailкоммуникаций
Защищенный обмен
документами
(аутентичность,
целостность и
конфиденциальность)
Транзакции
Веб-сервисы
Коммуникация
Транзакция /
интеграция
►
SSL/TLS
► МТТ версия 2
► ISIS-MTT
► МТТ версия 2
► ISIS-MTT
► XML-подпись и
XML-шифрование
► OSCI транспорт
версия 1.2
► WS-безопасность
Рис. 9-3: Стандарты безопасности для конкретных приложений
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
SSL/TLS базируется на TCP/IP и безопасных коммуникационных протоколах для
таких приложений, как HTTP, FTP, IIOP и др. прозрачным образом. К WWW-страницам,
защищенным SSL/TLS, обращаются через https://, а не http://.
Использование HTTP через SSL-защищенные подключения часто называется
HTTPS.
SSL/TLS поддерживает на одном конце аутентификацию сервера государственного
учреждения в отношении к клиенту партнера по коммуникации, для того чтобы заверить
последнего в том, что он действительно соединен с сервером государственного
учреждения.
SSL/TLS предлагает следующие криптографические механизмы.
a)
Асимметричная аутентификация коммуникационных партнеров (через
сертификаты X.509)
b)
Безопасный обмен сессионными ключами (через RSA-кодирование или
соглашение о ключах Diffie-Hellman)
c)
Симметричное кодирование коммуникационного содержания
d)
Симметричная аутентификация сообщений (через MACs) и защита от
ответных атак
Принципы операции SSL/TLS подробно описаны в разделе 5.2.2 Руководства по
внедрению электронной подписи и шифрования в администрацию, выпущенного
Комитетом сотрудничества по автоматизированной обработке данных для федерального
правительства, федерально-земельного правительства и сектора муниципальной
администрации (KoopA ADV). Комбинация различных методов называется в SSL/TLS
«набором шифров». Этот набор всегда содержит четыре криптографических алгоритма:
метод подписи, метод обмена ключами, метод симметричного шифрования и функция по
ненужной информации.
Руководство по внедрению электронной подписи и шифрования в администрацию,
выпущенное Комитетом сотрудничества по автоматизированной обработке данных для
федерального правительства, федерально-земельного правительства и сектора
муниципальной администрации (KoopA ADV) дает следующие рекомендации.
a) Для симметричных методов должна быть определена конкретная максимальная
длина ключа, т.е. нынешние 128 бит или 112-бит 3 DES и RC2 не рекомендуются.
b) SHA1 следует использовать для функции по ненужной информации.
c) RSA по модулю должен иметь как минимум 1024 бит.
9.3.2. Защита email-коммуникаций
Безопасный обмен электронными письмами - одно из возможных приложений для
«коммуникационной» стадии взаимодействия. Безопасная коммуникация электронных
писем включает их защиту во время передачи от отправителя к получателю. Это
приложение рассматривает электронные письма в их целостности. В разделе 9.3.3
«Защищенный обмен документами» описываются процедуры защиты документов,
включая вложения в электронные сообщения.
Обязательно:
MailTrust (MTT) версия 2 / SPHINX / PKI-1-Verwalfung
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
MTT версия 2
MTT-Spezifikation, версия 2 – это разработка German TeleTrust t.V.
Этот стандарт охватывает:
a)
b)
c)
Сертификаты X.509v3 и форматы списков аннулирования X.509-CRLv2
Формат документов S/MIME-v3
Управляющие сообщения PKCS и PKIX
Этот стандарт классифицируется как обязательный, потому что он составляет
основу как для проекта SPHINX, так и для администрации PKI. В будущем он может быть
заменен на ISIS-MTT (см. ниже).
SPHINX
Криптографические методы, используемые в SPHINX, составляют часть
спецификации МТТ. В пилотном испытании «SPHINX – безопасная электронная почта»
тестировалась сквозная безопасность электронных сообщений, основанная на
криптографии открытого ключа. Вся концепция разрабатывалась на базе спецификации
MailTrust (MTT версия 2) и охватывает стандарты для электронной подписи и
шифрования, а также инфраструктурные меры и организационные требования,
необходимые для внедрения технологии безопасности. На базе этой концепции была
разработана инфраструктура безопасности для государственных учреждений и
организаций, дающая возможность безопасного обмена документами между
пользователями.
Администрация PKI-1 – инфраструктура открытого ключа для государственных
органов
Отталкиваясь от опыта пилотного проекта SPHINX, BSI внедрил инфраструктуру
открытого ключа (PKI) для сектора администрации (Администрация PKI-1), Должен
использоваться Удостоверяющий центр (Policy Certification Authority – PCA)
администрации PKI-1. Федеральные органы, муниципальные администрации и другие
государственные учреждения эксплуатируют собственные удостоверяющие центры,
которые сертифицируются администрацией PCA-1. BSI предлагает документацию на
http://www.bsi.de/, касающуюся использования SPHINX в контексте администрации PKI-1.
Обязательно:
Спецификация взаимодействия индустриальной подписи (ISIS)-MTT
Спецификация ISIS-MTT рассматривает набор приложений для процессов защиты
электронного бизнеса (например, «защита» файла, почты, транзакции и времени) на базе
основных функциональных возможностей, т.е. электронной подписи, шифрования и
аутентификации.
ISIS-MTT – это дельта спецификация, которая основывается на существующих,
подходящих международных стандартах (S/MIME, PKIX, PKCS, X.509, ETSI, CEN ETSI).
Спецификация сосредоточивается на требованиях соответствия, которые должны
соблюдаться соответствующими компонентами PKI и приложениями во время
генерирования и обработки определенных объектов данных, таких как сертификаты.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Сфера применения спецификации ISIS-MTT была определена с помощью слияния
и унификации спецификаций MailTrust (версия 2, март 1999, TeleTrusT e.V.) и ISIS
(Industrial Signature Interoperability Specification, версия 1.2, декабрь 1999, Т7 e.V.)
Спецификация ISIS-MTT состоит главным образом из основного документа,
который основывается исключительно на профилировании (ограничении необязательных
характеристик) международных стандартов, и который поэтому должен обеспечивать
взаимодействие в международном масштабе. Основа ISIS-MTT – главная спецификация,
обязательная для всех производителей и поставщиков и по мере необходимости
дополняемая необязательными профилями. Уже имеющиеся профили “SigG-conforming
Systems and Applications” и “Optional Enhancements to the SigG-Profile” описывают
текущее состояние квалифицированных подписей в Германии.
Спецификация ISIS-MTT классифицируется как обязательная, т.к. она является
преемницей MTT v2, и последняя полностью интегрирована в ISIS-MTT. Как только ISISMTT станет поддерживаться подходящими продуктами (предположительно до конца 2003
г.), спецификация ISIS-MTT вытеснит стандарт MTT v2.
9.3.3. Защищенный обмен документами
«Коммуникационная» стадия взаимодействия требует обмена безопасными
документами. Это включает, например, защиту документов в качестве вложений в
электронные письма, а также защиту документов во всякого рода коммуникационных
путях.
Стандарты MTT v2 и ISIS-MTT подходят для защиты вложений в электронные
письма, тогда как XML – подпись и XML – шифрование, как специфические XMLстандарты, все более подходят для безопасного обмена XML-документами (например, для
форм, предназначенных для будущей обработки).
Обязательно:
MailTrust (MTT) версия 2 / SPHINX / администрация PKI-1
Спецификация MTT версии 2 (см. в разделе 9.3.2 «Защита email-коммуникаций»)
также определяет формат обмена взаимодействующими данными для подписанных и
шифрованных данных. МТТ рассматривает, кроме всего, защиту бинарных данных, с тем
чтобы была возможна передача файлов разного рода в качестве вложений в электронные
письма.
МТТ версия 2, проект SPHINX и администрация PKI поддерживают безопасный
сквозной обмен документами. МТТ версия 2 в будущем будет заменен на ISIS-MTT (сим.
Раздел 9.3.2).
Обязательно:
Спецификация взаимодействия индустриальной подписи (ISIS)-MTT
ISIS-MTT (см. раздел 9.3.2 «Защита email-коммуникаций») полностью интегрирует
МТТ версию 2 и в будущем заменит этот стандарт собою.
Обязательно:
XML подпись
XML подпись – это общий стандарт W3C и IETF (W3C, XML Signature Syntax and
Processing, W2C Recommendation and IETF RFC 3275, март 2002) (см.
http://www.w3.org/TR/xmldsig-core/).
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Этот стандарт описывает цифровые подписи для разного рода данных (обычно,
однако это XML), предоставляя XML-схему и набор правил обработки (для генерирования
и удостоверения подписи). Подпись может охватывать один или более документов и
различные виды данных (картинки, текст и т.д.).
Размещение XML-подписи возможно тремя способами:
a) Вложение в конверт: Подпись может быть встроена, т.е. XML-фрагмент,
представляющий подпись, вставлен в подписываемый документ.
b) Обертывание: Подпись может выступать в качестве конверта, т.е. она
прилагается к документу, на который ссылка сделана в подписи.
c) Отделение: подпись может быть независимой (отделенной), т.е. она держится
отдельно от источника, либо в том же, либо в другом XML-документе.
Одним из главных свойств XML-подписи является то, что можно подписывать
только отдельные части XML-документа, а не весь документ. Могут применяться как
асимметричные криптографические алгоритмы, так и симметричные методы. Это
выбирается в зависимости от цели защиты.
Благодаря этой гибкости, например, можно защитить целостность определенных
элементов XML-документа, тогда как другие его части могут редактироваться. Возьмем,
например, подписанную XML-форму, посылаемую пользователю. Пользователь может
заполнить определенные поля, не нарушая целостности документа. Это было невозможно
при условных подписях, потому что всегда подписывался полный документ, так что
любое изменение или дополнение означало нарушение его целостности.
Специфицируются следующие криптографические алгоритмы:
a)
b)
c)
d)
Функция по ненужной информации: SHA1
Кодирование: base64
MAG: HMAC-SHA1 (симметричные ключи); (HMAC RFC 2104)
Подпись: DSA SHA1 (DSS); дополнительно рекомендуется: RSA SHA1
Специализация
криптографических
предпочтений
коммуникационных сценариев еще не происходит.
Рекомендуется:
для
конкретных
XML шифрование
XML шифрование – это стандарт W3C, однако в отличие от XML-подписи, еще не
RFC (XML Syntax and Processing, W3C Recommendation, 10 декабря 2002)
XML шифрование предоставляет XML-схему и набор правил обработки (для
шифрования / дешифровки), которые поддерживают шифрование /дешифровку полных
документов, частей документов (элементов) или содержания элементов.
Для шифрования могут применяться и симметричный, и асимметричный ключи.
Специфицируются следующие криптографические алгоритмы:
a)
b)
c)
Шифрование блоков 3DES, AES
Транспорт ключа: RSA (алгоритм RSAES-PKCS1-v1_5, RFC 2437)
Соглашение о ключе: Diffie-Hellman (необазательное)
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
d)
e)
Функция по ненужной информации: SHA1, RIPEMD-160
Кодирование: base64
XML шифрование рекомендуется в дополнение к XML-подписи. Однако этот
стандарт еще не признается в той же степени, что и XML-подпись.
9.3.4. Транзакции
Транзакции охватывают сложные, специализированные бизнес-примеры
многостадийной цепочкой стоимости между коммуникационными партнерами.
Обязательно:
с
Online Service Computer Interface (OSCI)-Transport v1.2
OSCI – Интерфейс компьютера онлайнового сервиса (см. http://www.osci.de/)
является результатом конкуренции; MEDIA@Komm. OSCI охватывает хост протоколов,
которые подходят для потребностей е-правительства и которые реализуются руководящей
группой OSCI. Цель – поддержка транзакций в форме веб-сервисов и их полное
осуществление через Интернет.
OSCI Transport 1.2 – это та часть “OSCI”, которая отвечает за кросс-секционные
задачи в области безопасности. Существование центрального посредника, который может
выполнять услуги повышенного качества без риска для конфиденциальности на уровне
данных бизнес-случая, - характерная черта безопасного осуществления процессов еправительства с применением OSCI. Будучи протоколом защищенной трансмиссии, он
позволяет связывать онлайновые транзакции (даже в соответствии с Германским Актом о
цифровой подписи).
OSCI Transport поддерживает асинхронную коммуникацию через посредника, а
также сквозное шифрование для конфиденциальной трансмиссии данных. OSCI Transport
стандартизирует как содержание сообщений, так и функции транспорта и безопасности, и
базируется на международных стандартах (включая, например, XML Signature, DES, AES,
RSA и X.509) для которых по мере необходимости разрабатывается подходящее,
конкретное содержание.
Главными критериями дизайна OSCI Transport, версия 1.2 были следующие.
a) Ссылка на открытые стандарты (SOAP, XML Signature, XML Encryption)
b) Техническая независимость, т.е. трансмиссия с помощью любого протокола
технической коммуникации без каких-либо специфических требований, касающихся
платформ или языков программирования
c) Масштабируемость уровней безопасности (авансированные подписи или
квалифицированные и / или аккредитованные электронные подписи, если этого требует
конкретное приложение).
9.3.5. Веб-сервисы
Все возрастающее значение XML в качестве формата обмена данными и
спецификаций даже в области безопасности и внедрение веб-сервисов в качестве
интегративных микропрограммных средств ведут к активной стандартизации стандартов
XML безопасности специалистами W3C и OASIS. Сейчас пока еще невозможно оценить
обоснованность и окончательную сферу применения проектов.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
При соблюдении: Web Services (WS) Security
WS-Security (см. http://www-106.ibm.com/developerworks/library/ws-secure/) это
новый отраслевой стандарт для безопасности веб-сервисов. Он определяет апгрейды
протокола SOAP с целью предоставления и обеспечения конфиденциальности,
целостности и обязывающего эффекта сообщений SOAP по защите веб-сервисов. Должно
быть возможно использование различных моделей безопасности и другого
криптографического метода.
WS-Security также позволяет использовать различные “security tokens”, т.е.
форматы данных, гарантирующие конкретные тождества или свойства, например,
сертификаты Х.509б Kerberos Tickets или шифрованные ключи.
WS-Security рассматривается как базовый документ по безопасности веб-сервисов,
за которым должны в будущем последовать другие документы (WS-Policy, WS-Trust, WSPrivacy, WS-Secure Conversation, WS-Federation и WS-Authorization).
WS-Security является совместной разработкой компаний IBM, Microsoft и Verisign,
отсюда и сильная поддержка производителей. Хотя сейчас пока еще невозможно
окончательно оценить обоснованность этого стандарта, он вполне может иметь большое
значение для SOAP-коммуникации будущих веб-сервисов.
9.4.
Общие стандарты безопасности данных
Общие стандарты безопасности охватывают те стандарты, которые не могут быть
присвоены конкретным приложениям и / или стадиям взаимодействия, см. рис. 9-4.
Интеграция
► ISIS-MTT
инфраструктуры
безопасности
Интеграция смарткарт
► ISO/IEC 7816
Управление ключами
►XKMS v2
Криптографические
► Публикация RegTP (функции по ненужной информации:
алгоритмы для электронной RIPEMD-160, SHA1; алгоритмы подписи: RSA, DSA,
подписи
варианты DSA)
Симметричные
► Triple-DES, IDEA, AES
криптографические
алгоритмы
Рис. 9-4: Общие стандарты безопасности
9.4.1. Аутентификация
Для обеспечения достижения цели аутентификации как защитного средства,
некоторые приложения е-правительства требуют идентификации и аутентификации
коммуникационных партнеров.
Модуль «Аутентификация в е-правительстве» (см.
пособие по е-правительству http://www.bsi.bund.de/fachthem/egov/6.htm) пособия по еправительству рассматривает технические аспекты различных методов аутентификации.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
9.4.2. Интеграция инфраструктуры безопасности
Инфраструктура безопасности включает компоненты директории, сертификации и
проставления времени, которые поддерживают распределение и регулирование
сертификатов, списков аннулирования и проставления времени как для электронной
почты, так и для веб-среды. Доступ к этим компонентам происходит через операционные
протоколы.
Обязательно: Industrial Signature Interoperability Specification (ISIS)-MTT
ISIS-MTT (см. раздел 9.3.2 «Защита email-коммуникаций») описывает, в разделе 4
«Операционные протоколы», протоколы и профили для соединения инфраструктур
безопасности. Они включают в себя доступ к директориям через LDAP v3, Online
Certificate Status Protocol (OCSP), FTP и HTTP, а также Time Stamp Protocol (TSP).
9.4.3. Интеграция смарткарт
Интеграция смарткарт, считывающих устройств для смарткарт и архитектур их
драйверов и / или комплексных, многофункциональных «Смарткарт / пакетов
считывающих устройств» необходима, например, для использования квалифицированных
электронных подписей в сочетании с клиентской инфраструктурой.
Инициатива D21 (см. http://www.initiatived21.de/) занимается этим вопросом через
свою рабочую группу 5 – «Проект смарткарт». Результаты работы этой группы дополнят
вышеперечисленные стандарты интеграции смарткарт.
Обязательно: ISO/IEC 7816
Смарткарты (чип-карты) должны соответствовать стандарту ISO/IEC 7816.
Компоненты, поддерживающие универсальный “Cryptographic Token Interface” (Cryptoki)
должны согласовываться с частью 7 ISIS-MTT (Cryptographic Token Interface).
9.4.4. Управление ключами
Как условие для приложений, использующих электронные подписи, должна быть
возможность присваивать открытые электронные ключи (открытые ключи) реальным
лицам и учреждениям. Для достижения взаимодействия между различными
приложениями должны быть в наличии идентичные форматы данных и должны
применяться стандартизированные механизмы для чтения и написания данных.
Рекомендуется: XML Key Management Specification (XKMS) v2
XKMS (см. http://www.w3.org/TR/xkms2/) специфицирует протоколы для
регистрации и распределения открытых ключей. Протоколы
предназначены для
взаимодействия с XML Signature и XML Encryption, и поэтому используются для
коммуникаций на базе XML типа веб-сервисов. Спецификация состоит из двух частей –
XML Key Registration Service Specification (X-KRSS) и XML Key Information Service
Specification (X-KISS).
Клиенты могут пользоваться относительно простыми запросами XKMS для
нахождения и подтверждения подлинности открытых ключей, с релейными серверами,
имеющими доступ к имеющимся инфраструктурам LDAP и OCSP для ответа на эти
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
запросы. Это означает, что параллельное использование различных сервисов директории
возможно лишь с одним протоколом.
9.4.5. Криптографические алгоритмы для электронной подписи
Безопасность электронной подписи зависит главным образом от силы лежащих в ее
основе криптографических алгоритмов. Относительно «электронной подписи» см. также
раздел 4.1.5.1.
Обязательно: Криптографические алгоритмы для электронной подписи согласно RegTP –
Regulatory Authority for Telecommunications and Posts
Каждый год RegTP публикует те криптографические алгоритмы, которые могут
считаться пригодными как минимум на ближайшие шесть лет с учетом выполнения
требований Германского Акта о подписи (SigG) и Ордонанса о цифровой подписи (SigV)
– см. http://www.regtp.de/tech_reg_tele/in_06-02-02-00-00_m/03/). Федеральный офис
Германии по информационной безопасности (BSI) может классифицировать дальнейшие
методы как пригодные.
Электронная подпись для целей Акта включает следующие криптографические
алгоритмы.
a) Алгоритм для случайных данных (т.е. функция по ненужной информации),
который сокращает данные, которые должны быть подписаны, до значения случайных
данных, т.е. битовой цепочки постоянной длины. Это далее означает, что подписывается
значение случайных данных, а не сами данные.
b) Метод асимметричной подписи, который состоит из подписывающего и
верификационного алгоритма. Метод подписи зависит от пары ключей, состоящей из
закрытого (секретного) ключа для подписания (генерирования) и подходящего открытого
ключа для подтверждения(проверки) подписи.
c) Метод создания пар ключей для отдельных коммуникационных партнеров.
Подходящие функции случайных данных
a)
RIPEMD-160
b)
Это криптографическая функция ненужной информации, которая, как и
SHA1, генерирует значения случайных данных длиной в 160 бит.
c)
SHA1
d)
SHA1 (Secure Hash Algorithm) – это очень широко применяемая
криптографическая функция случайных данных. SHA1 обрабатывает блоки длиной в 512
бит и генерирует значения случайных данных длиной в 160 бит.
Подходящие алгоритмы подписи
a)
RSA
b)
RSA был разработан Ривестом, Шамиром и Адлеманом. Это наиболее
важный асимметричный метод, называемый также методом открытого ключа.
Безопасность базируется на трудности разложения на множители больших натуральных
чисел. Обычно длина показателя степени составляет 512, 1024 и 2048 бит, при этом 512битовые ключи больше не рекомендуются.
c)
DSA
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
d)
Digital Signature Algorithm (DSA) – этот метод подписи, разработанный и
специфицированный в 1991 г. в Стандарте цифровой подписи США (DSS). DSA – это
просто алгоритм подписи (RSA, напротив, позволяет и электронную подпись, и обмен
ключами). Хотя правительство США получило патент на DSS. Но его использование
бесплатное.
e)
Варианты DSA базируются на эллиптических кривых (EC-DSA, EC-KDSA,
EC-GDSA, Nyberg-Rueppel подписи).
На пригодность и /или специфическую форму алгоритмов, которые нужно
применять, могут влиять применимые стандарты; ISIS-MTT часть 6, например,
специфицирует криптографические алгоритмы, действительные для ISIS-MTT.
9.4.6. Симметричные криптографические алгоритмы для шифрования
Криптографические алгоритмы для шифрования могут применяться к данным и /
или ключам для обеспечения их конфиденциальной трансмиссии.
Симметричные методы, если они применяются, пользуются одним и тем же
закрытым ключом и для шифрования, и для дешифровки. Эти методы обычно отличаются
очень высокой производительностью.
Хотя RegTP не специфицирует никаких алгоритмов шифрования, в этом случае
приняты алгоритмы, специфицированные в ISIS-MTT, часть 6. В случае сомнения
спецификации стандарта ISIS-MTT превалируют. В отношении режима и набивки
каждого данного алгоритма делается ссылка на ISIS-MTT, часть 6.
Обязательно: Triple Data Encryption Algorithm (Triple-DES)
Triple-DES
(см.
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf),
называемый также 3DES, является вариантом троцного DES, т.е. симметричным
алгоритмом шифрования с эффективной длиной ключа в 168 бит. 3DES использует три
ключа DES по 56 бит каждый. Хотя этот метод считается безопасным, он не отличается
очень высокой производительностью.
Обязательно: International Data Encryption Algorithm (IDEA)
IDEA был разработан в Европе и характеризуется длиной ключа 128 бит.
При соблюдении: Advanced Encryption Standard (AES)
AES (см. http://csrc.nist.gov/)– это симметричный блоковый шифр, который заменит
собою Triple DES в качестве стандарта, и который кодирует 128-битовые блоки данных с
длинами ключа в 128, 192 или 256 бит. Следующая версия ISIS-MTT будет включать AES
в части 6 (Криптографические алгоритмы).
Приложение А Основные модели инициатив BundOnline
A.1 Основной компонент - Платежная платформа («е-payment»)
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
A.2 Основной компонент – Безопасность данных («virtual post office»)
A.3 Основной компонент – Портал
Введение
Портал Bund.de как основной компонент является центральной точкой доступа к
электронным услугам и информационным предложениям по Интернет федеральных
агентств. Система управления контентом дает доступ распределенным пользователям и
дает возможность всем организациям общественной власти и агентствам публиковать
информацию через портал.
Портал предоставляет адреса федеральных агентств и дальнейшую информацию
касательно организационный структур и услуг отдельного общественного агентства.
Портал предоставляет центральные информационные услуги, такие как вакансии в
администрации, публикация не электронных приглашений на тендер, информация о
распродажах в администрации, и т.д. Информационные предложения портала, число услуг
предоставляемых централизованно и интерфейсы будут постепенно расти.
Все общественные агентства призваны просматривать его, если это необходимо, с
поддержкой редакторов портала – на предмет обновления и полноты.
Контактная информация
Черты
Лежащая в основе портала технология, в настоящий момент система
редактирования портала от компании (…) и поисковая система от FAST (бывшая
Altavista). Портал перенесен на CMS основной компонент (секция А.5) инициативы
BundOnline 2005. (система редактор САР 4.1 от CoreMedia). Данные Bund.de обновлены и
поддерживаются местными редакторами и командой редакторов портала, работающих
рассредоточено. Информация, предоставляемая общественным агентством всегда
находится под редакторским контролем.
Портал создается в несколько этапов, в двух случаях из трех реализуются
следующие этапы.
Этап 1.
С СeBitа в марте 2000 года, основные функции и «Поиск» и «Найти» доступны уже
на Этапе 1. Т.о. портал появляется перед Интернет-пользователями в форме каталога с
поисковой системой.
Каталог помогает находить информационные предложения и услуги в форме
аннотированных ссылок, разделенных по предметам. Базы данных публичных агентств
обновляются децентрализовано и охватывают Высшие конституционные органы, всю
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
федеральную власть и большинство институционных адресатов фонда, таких как
библиотеки, музеи и исследовательские институты. Федеральные земли представлены
своими конституционными органами, dscist административные уровни и дальнейшие
общественные агентства, пока городской уровень представлен центральными
организациями и большими городами.
Функция централизованного полнотекстового поиска основана на поиске индекса,
который покрывает полное предложение от всех публичных агентств. Функция гео-поиска
показывает карты с расположением публичных агентств. Несколько колонок портала
предлагает пользователям возможность зарегистрировать подписки е-почты. Любая
информация, которая снова опубликована на портале, редактирующая система
немедленно передается по е-почте.
Пользователи отсылают запросы общественным агентствам посредством
контактных форм, по е-почте, факсом или телефоном. Редакционная команда портала
отвечает на запросы либо передает их соответствующему агентству для дальнейших
процедур.
Этап 2.
Фокусная задача второго этапа была создание постановления о свободных от
барьеров информационных технологиях, которые вступают в силу 24 июля 2002.
число центральных услуг по требованию будет увеличиваться. В СeBit в марте
2000 года, федеральный портал администрации www.bund.de выйдет в интерактивный
режим при условии свободы от барьеров.
Кроме того, ревизия портала в соответствии с Предписанием (Приказом) на
создание информационных технологий свободных от барьеров, число центральных услуг
по требованию было увеличено. В 2002 году наиболее важные формы федеральной
администрации, например, был сделан доступным через новый онлайн центр портала (см.
А.4). Центр поиска работы, продаж и приглашений на тендер был обновлен добавлением
новых функций. Городская функция поиска сейчас предлагает весь спектр важной общей
информации в интерактивном формате.
Этап 3.
Этап 3 будет обозначить миграцию портала на CMS основной компонент
инициативы BundOnline 2005. Проект миграции планируется завершить к середине 2004
года. За этим последует создание ориентированной на знания онлайн информационной
системы через портал. Это может помочь в сокращении расходов на редактирование
портала и значит расширение функций хелп дэска (стола помощи).
Когда электронные услуги федерального правительства будут разработаны в 2005
году, эти услуги будут тогда полностью доступны для исследования посредством услуг
портала федерального правительства.
Бизнес ситуации
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Рассмотренные ниже Бизнес ситуации могут служить ориентировочной целью для
решений, касающихся использования портала и его функций.
Поддержка и обновление центральной базы данных федерального правительства
(основные (сводные) данные публичного агентства)
a)
Собраны все опубликованные основные (сводные) данные публичного
агентства .
b)
Эта информация была импортирована на портал через систему
редактирования портала, либо через интерфейсы, реализующие импорт, на базе XML.
c)
Данные экспортированы на XML основу. Доступны Web услуги.
Эта бизнес ситуация необходима. Параллельное обеспечение адресов публичных
агентств на портале и в директории услуг информационной сети Берлин-Бонн (около 860
федеральных властей на портале и около 100 в сети Берлин-Бонн) будет изменено
расположение вместе с экспортом данных на базис XML и обеспечение этих данных для
обновления директории информационной сети Берлин-Бонн.
Поддержка и обновление центральной базы данных федерального правительства
(услуги)
a)
b)
на портале.
c)
Собрана информация об услуге.
Используется система редактирования портала для публикации информации
Данные экспортируется на базис XML.
Эта бизнес ситуация необходима.
Поддержка и обновление центральных информационных услуг (формы, вакансии,
не-электронные приглашения на тендер и распродажи)
a)
Собираются предложения для публикации.
b)
Используется система редактирования портала, для публикации
информации на портале.
c)
Данные экспортированы на XML основу. Доступны Web услуги.
1)
Эта бизнес ситуация рекомендуются. Обмен с внешними информационными
услугами на базисе XML и/или web-услуги планируемые в будущем.
2)
Поддержка и обновление предложения «Самые последние новости»
d)
Собираются самые последние новости, предназначенные для публикации
редактор.
e)
Используется система редактирования портала, для публикации
информации на портале.
Эта бизнес ситуация рекомендуются.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Поддержка и обновление информации предложенной федеральным государством
a)
Собирается федерально-земельная информация для публикации на сайте.
b)
Используется система редактирования портала, для публикации
информации на портале.
Эта бизнес ситуации находится на рассмотрении. Все федеральные структуры в
общем имеют возможность самим обновлять информацию публичных агентств используя
систему для редактирования компании (…). Замена основанной на XML системой обмена
данными и/или через web – услуги планируется в течение курса проекта миграции.
Поддержка и обновление городских данных
a)
Информация, касающаяся городов, районов и муниципалитетов
публикации получается из внешних источников.
b)
Используется обычный порядок системы редактирования портала
публикации информации на портале.
для
для
Эта бизнес ситуация рекомендуется.
Поддержка и обновление информационных предложений BundOnline 2005
a)
Собирается информация, касающаяся BundOnline и развития инициатив для
публикации.
b)
Используется система редактирования портала, для публикации
информации на портале.
c)
Данные об услугах BundOnline может быть экспортирована на базис XML.
Интерфейсы
Существующие интерфейсы используют функции экспорта и импорта системы
редактирования компании (…). Интерфейсы CMS - основного компонента инициативы
BundOnline 2005 будет использовать следующую миграцию.
Web-услуги
Следующие web-услуги в данное время реализуются
a)
b)
Основные данные публичного агентства
Действующие приглашения на тендер.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
c)
d)
e)
Действующие вакансии
Действующие распродажи
Географическое положение адресатов (стр 124)
Эти web-услуги доступных ограниченной группе пользователей и располагаются
на UDDI сервере.
Экспорт данных
Эта система редактирования компании (…) включает операции вмешательства
(интервенции) (стр. 124) для экспорта данных, которые редактор портала может
использовать для записей экспорта данных. Функциональности экспорта включают
следующие операции.
a)
Входы на порталы публичных агентств могут быть экспортированы
отдельно либо вместе с подходящими адресами (публичные агентства: данные адреса =
1:n).
b)
Входы на порталы публичных агентств и адреса могут быть также
экспортированы как файлы, разделенные точкой.
c)
Полная адресная директория в bund.de может быть загружена
(экспортирована) как PDF файл.
d)
Следующая раскрытая организационная информация публичных агентств
может быть экспортирована в XML формате.
1.
Адреса/действительные свойства публичных агентств
2.
Партнеры
3.
Агентства уровнем ниже
4.
предметы в каталоге
5.
услуги и услуги BundOnline
6.
Формы
7.
Вакансии
8.
Приглашения на тендер
9.
Распродажи
X.500 экспорт
Адреса публичных агентств доступны в формате CSV для услуги директории
информационной сети Берлин-Бонн для импорта через интерфейс X.500.
Импорт данных
Основные данные публичного агентства могут быть импортированы через
определенный XML формат для публикации входов и адресов публичных агентств.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Основной компонент «сервер норм»
Основной компонент «сервер норм» включает центр форм на своем первом этапе
портала bund.de. Для получения полной информации можете обратиться к секции А.4.
А.4 Основной компонент - Сервер форм
А.5 Основной компонент – система управления контентом
А.6 Компонент инфраструктуры
администрации
– Информационная Сеть
Федеральной
А.7 Сервис директорий как компонент инфраструктуры
А.8 Услуга «Одна для всех»
А.9 Центры компетенции
CMS (content management system) – система динамического
обновление и редактирования содержания Интернет-сайта.
Системы класса ERP (Enterprise Resource Planning) – это комплекс
интегрированных приложений, позволяющих создать единую среду для автоматизации
планирования, учета, контроля и анализа всех основных бизнес-процессов предприятия.
Front-end - это транслятор входного языка в промежуточное представрение, т.е.
front-end должен из последовательнлости лексем построить синтаксическое дерево
разбора.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»
Back-end - это транслятор промежуточного представления в код конкретной
машины.
Перевод с английского языка осуществлен в ЗАО «Национальные Информационные Технологии»