Какие модели архитектуры удостоверяющих центров применяются на практике

21.Модели доверия уц. Иерархическая модель.

Понятие доверия является в PKI краеугольным, то есть вся система с ключами и сертификатами работает в случае доверяя пользователей некой 3 доверенной стороне (УЦ). Поскольку Удостоверяющих Центров может быть больше 1, то схема их взаимодействия порождает различные модели доверия(иерархическая, сетевая,мостовая).

Иерархическая модель.

УЦ0-корнвой УЦ сам себе выдает сертификат.

В случае, когда между собой взаимодейств-т пользователи одного и того же УЦ, например, А и В, проблем с проверкой подлинности сертификатов нет. А и В доверяют УЦ111 и имеют его корневой сертификат, поэтому могут проверить сертификат любого пользователя УЦ 111.

При взаимодействии а и С ситуация усложняется: А не доверяет УЦ 121, т.к.не я вяется его пользователем и не имеет его сертификата. Аналогично, С не доверяет УЦ 111.Решение:

1. А обращается в свой родной УЦ и узнает, какой УЦ выпускал для него сертификат: УЦ11 является родителем.
2. А запрашивает сертификат УЦ11.
3. Повторяя пункты 1 и 2 пользователь добирается до коренного УЦ0 и получает его сертификат. Процедура м.б.проще, если при регистрации А ему сразу выд-ся вся цепочка сертификатов.
4. А узнает, какая цепочка сертификатов нужна для проверки С. Эта информация содержится в самом сертификате С.
5. Зная корневой сертификат УЦ0, проверяется следующий сртификат в цепочке
6. Убедившись, что сертификат УЦ12 верен, с его помощью проверяется сертификат УЦ121, а затем и сертификат С.

22.Модели доверия уц. Сетевая модель.

Понятие доверия является в PKI краеугольным, то есть вся система с ключами и сертификатами работает в случае доверяя пользователей некой 3 доверенной стороне (УЦ). Поскольку Удостоверяющих Центров может быть больше 1, то схема их взаимодействия порождает различные модели доверия(иерархическая, сетевая,мостовая). Сетевая модель. В данной модели все УЦ являются независимыми, никто никому не подчиняется. Пользователи одного и того же УЦ легко друг с другом взаимодействуют, т.к.доверяют одному и тому же УЦ. Пользователи разных УЦ между собой взаимодействовать не могут, т.к.нет доверия между разными УЦ и проверить сертификаты другого УЦ невозможно. Решением проблемы явл-ся исп-е мех-ма кросс-сертификации. Кросс-сертификация – процесс установки доверит отношений между ранее не связанными УЦ. Он заключается в использовании кросс-сертификатов:

1. УЦ5 запрашивает у УЦ3 его самоподписанный сертификат.Данный серт-т должен быть получен защищенным способом(лично или по защищенному каналу связи)
2. Уц5 подпис-т полученный от УЦ3 сертификат своим закрытым ключом, тем самым подтверждая, что он доверяет УЦ3. Дважды подписанный сертификат и есть кросс-сертификат.
3. Аналогично поступает УЦ3.
4. Пользователь А желает проверить подлинность серт-та С. Для этого он берет кросс-сертификат в УЦ5, проверяет его подлинность с помощью сертификата УЦ5. Т.о.А убежд-ся, что открытый ключ УЦ3 достоверен и им можно пользоваться.
5. С помощью уже достоверного сертификата УЦ3 и ключа, который в нем лежит, проверяется подлинность сертификата С.

+ Компрометация любого из УЦ фатальна только для его пользователей и не касается других — Для большой сети из N УЦ каждому УЦ придется получить N-1 кросс-сертификат.

Иерархическая модель доверия удостоверяющих центров

Целью лабораторной работы является ознакомление с одной из базовых моделей доверия, применяемой при построении архитектуры инфраструктуры открытых ключей. В данной работе будет изучена работа удостоверяющих центров при иерархической модели доверия, рассмотрены особенности работы на каждом из уровней, работа операторов на каждом из уровней сертификации.

Ход работы

Для того, чтобы создать подчиненный УЦ для нашей кафедры, воспользуемся изначальной виртуальной машиной, использованной при создании нашего персонального УЦ. Запустим виртуальную машину «PKI lab». Для того, чтобы ввести новый (кафедральный) удостоверяющий центр в подчинение к факультетскому удостоверяющему центру необходимо ввести виртуальную машину в домен факультета.

Данная операция потребует предварительной подготовки. Иначе при добавлении компьютера в домен может быть получена ошибка.

Для того, чтобы исправить данную проблему, воспользуемся утилитой Sysprep. Запуск ее осуществляется из директории (рисунок 1), в которой расположена утилита следующей командой:

sysprep /oobe /generalize

Рисунок 1 – Вызов утилиты в командной строке

Следующим шагом потребуется внести изменения в параметры сетевых адаптеров обоих виртуальных машин. В свойствах у IP версии 4 укажем для удостоверяющих центров факультета и кафедры IP-адреса 192.168.0.1 и 192.168.0.2 соответственно (рисунок 2).

Рисунок 2 – Настройка IP адресов на виртуальной машине

Создадим на виртуальной машине УЦ ФБ учетную запись для управления подчиненным удостоверяющим центром. Для этого запустим оснастку «Пользователи и компьютеры Active Directory» через меню «Средства» диспетчера серверов (рисунок 3).

Рисунок 3 – Вызов оснастки «Пользователи и компьютеры Active Directory»

В открывшемся окне выберем домен «tusur.ru» и вызовем контекстное меню. В нем выберем пункт «Создать», а в предложенном списке вариантов «Пользователь».

В качестве имени пользователя можете указать привычную связку, соответствующие номеру нашей группы и нашим инициалам (рисунок 4).

Рисунок 4 – Параметры создаваемого пользователя

Зададим в качестве имени компьютера название кафедры (рисунок 5) и укажем, что компьютер является частью домена tusur.ru. После нажатия на кнопку «ОК» потребуется указать логин и пароль пользователя. Укажем данные созданного нами пользователя (рисунок 6).

В результате система выдаст сообщение об успешном подключении к домену данной виртуальной машины (рисунок 7).

Рисунок 5 – Подключение виртуальной машины к домену

Рисунок 6 – Ввод учетных данных для подключения к домену

Рисунок 7 – Уведомление об успешном включении в домен

Выдадим права подчиненному серверу на изготовление сертификатов. Для этого на виртуальной машине УЦ ФБ снова откройте оснастку «Пользователи и компьютеры Active Directory» и во вкладке «tusur.ru» выбираем раздел «Users». Находим там пользователя созданного нами пользователя, под чьим именем мы вошли на виртуальной машине кафедрального УЦ.

Зайдем в свойства данного пользователя и перейдем во вкладку «Член групп». Нажмем на кнопку «Добавить». В открывшемся окне в поле «Введем имена выбираемых объектов» укажем «Издатели сертификатов» (рисунок 8).

Рисунок 8 – Добавление пользователя в группу «Издатели сертификатов»

В первую очередь необходимо установить доменные службы Active Directory. В открывшемся мастере добавления ролей и компонентов для текущего сервера выберем соответствующий компонент. По окончанию установки компонента нажмем на ссылку «Повысить роль этого сервера до уровня контроллера домена».

В открывшемся окне мастера выберем опцию «Добавить контроллер домена в существующий лес» (рисунок 9) и укажем логин и пароль администратора домена

Рисунок 9 – Добавление контролера домена в существующий лес

После окончания установки компонентов нажмем на ссылку «Настроить службы сертификатов Active Directory». В открывшемся конфигураторе выберем оба установленных компонента. В качестве варианта установки центра сертификации выберем «ЦС предприятия», а на следующем шаге «Подчиненный ЦС» (рисунок 10).

Рисунок 10 – Выбор типа ЦС

Выберем пункт «Отправить запрос сертификата в родительский ЦС». В противном случае потребуется копировать файл на другую виртуальную машину и вручную проводить обработку запроса, а после вручную копировать полученный сертификат на подчиненном удостоверяющем центре. Далее нажмем на кнопку «Выбрать» и в открывшемся окне выберем корневой центр сертификации (рисунки 11-12).

Рисунок 11 – Запрос сертификата из родительского ЦС

Рисунок 12 – Выбор родительского центра сертификации

В следующих разделах оставим параметры по умолчанию и нажмем на кнопку «Настроить».

После окончания настройки проверьте работоспособность локального центра сертификации. Запустим Internet Explorer и в адресной строке укажем путь к своему ЦС. По умолчанию это http://192.168.0.2/certsrv. В качестве примера показан вход по адресу http://kibevs.tusur.ru/certsrv (рисунок 13-14).

Рисунок 13 – Ввод учетных данных для входа на подчиненный ЦС

Рисунок 14 – Подчиненный центр сертификации

Далее проверим возможность подключения подчиненного центра сертификации к корневому. Для этого в адресной строке пропишем путь к нему и войдем под текущей учетной записью (рисунок 15).

Рисунок 15 – Корневой центр сертификации

Перейдем к виртуальной машине с корневым центром сертификации (УЦ ФБ). На данном этапе необходимо проверить, что подчиненному сертификату был выдан соответствующий сертификат. Для этого запустим оснастку «Центр сертификации». В разделе выданные сертификаты выделим последний выданный сертификат (рисунок 16). Зайдем в свойства сертификата (рисунок 17).

Рисунок 16 – Список выданных сертификатов

Рисунок 17 – Свойства сертификата подчиненного ЦС

Запустим третью виртуальную машину и установим на ней КриптоАРМ в режиме настраиваемой установки (рисунок 18-19).

Рисунок 18 – Запуск установки КриптоАРМ

Рисунок 19 – Выбор установки всех доступных модулей

Для полного соответствия получаемой иерархии схеме на рисунке 2 включим третью виртуальную машину в домен tusur.ru. Для этого потребуется изменить параметры сетевого адаптера (рисунок 20) и отключить брандмауэр.

Рисунок 20 – Изменение параметров сетевого адаптера третьего уровня иерархии

Необходимо добавить компьютер в домен tusur.ru (рисунок 21).

Рисунок 21 – Добавление компьютера в домен tusur.ru

После перезагрузки виртуальной машины зайдем под доменной учетной записью. Запустим Internet Explorer и в адресной строке укажем путь к подчиненному ЦС. По умолчанию это http://192.168.0.2/certsrv. От Вас потребуется ввести логин и пароль (рисунок 22)

Рисунок 22 – Подключение к подчиненному центру сертификации

В результате успешной авторизации на виртуальной машине нижнего уровня отобразится веб-интерфейс подчиненного центра сертификации (рисунок 23).

Рисунок 23 – Подчиненный центр сертификации

Далее необходимо получить сертификат от подчиненного центра сертификации. Запросим стандартный сертификат пользователя. Для этого последовательно вызываются функции «Запрос сертификата», «Сертификат пользователя» и «Выдать» (рисунок 24).

Рисунок 24 – Выдача сертификата

В результате проделанных действий будет получен сертификат (рисунок 25). Установим сертификат нажатием на соответствующую команду. Далее мы можем просмотреть содержание сертификата через соответствующую оснастку. В общих свойствах сертификата можно увидеть, что выдан этот сертификат был подчиненным центром сертификации – KIBEVS, а получателем является нижний уровень иерархии (рисунок 26).

Рисунок 25 – Получение сертификата

Рисунок 26 – Общие сведения сертификата

Более интересной будет вкладка «Путь сертификации» (рисунок 27), в которой можно увидеть полное дерево иерархии от корневого центра сертификации до текущего уровня.

Рисунок 27 – Путь сертификации

Вернемся к работе с КриптоАРМ. Для этого создадим на рабочем столе текстовый документ с любым непустым содержанием. После этого запустим КриптоАРМ и нажмем кнопку «Подписать» (рисунок 28).

В результате будет запущен мастер создания электронной подписи (рисунок 29), которому потребуется последовательно сообщить настройки для нового профиля подписи (в дальнейшем его можно будет выбирать для автоматизации процесса).

Рисунок 28 – Интерфейс программы КриптоАРМ

Рисунок 29 – Мастер создания электронной подписи

Выберем ранее созданный файл нажатием на кнопку «Добавить файл». В результате будет открыт «Проводник» для поиска необходимого файла.

В разделе «Свойства подписи» для пункта «Использование подписи» выберем вариант «Подписано», а в поле «Включить в подпись» – «Все сертификаты пути сертификации» (рисунок 30). Остальные параметры на данной вкладке можно оставить по умолчанию.

Рисунок 30 – Свойства создаваемой электронной подписи

Далее от пользователя потребуется указать сертификат, с помощью которого можно проставить электронную подпись на выбранный документ. Этот сертификат мы ранее получили от подчиненного удостоверяющего центра.

Нажмем на кнопку «Выбрать» для перехода к обзору содержимого хранилища сертификатов. Здесь можно найти ранее добавленный в хранилище сертификат, полученный от подчиненного центра сертификации. В случае, если необходимого сертификата в списке не будет – его можно добавить путем нажатия на кнопку «Импорт» и поиском по проводнику. В результате в меню выбора сертификата будет отображена основная информация по выбранному сертификату. Также здесь можно просмотреть содержание сертификата.

В результате выполнения описанных действий будет произведена электронная подпись выбранного документа. Об этом нам будет выведено соответствующее уведомление (рисунок 31), а в директории с подписанным файлом появится файл электронной подписи (рисунок 32).

Рисунок 31 – Уведомление об успешном проставлении электронной подписи

Рисунок 32 – Файл электронной подписи рядом с подписанным документом

Данный файл подписи можно открыть с помощью КриптоАРМ и просмотреть его содержание (рисунок 33). Для этого необходимо выбрать файл и нажать кнопку «Просмотр».

В результате выполнения данного действия откроется меню управления подписанными данными (рисунок 34). В данном окне можно выполнить ряд операций над подписанным документом, но для нас в рамках лабораторной работы будет интересен пункт «Просмотреть».

Рисунок 33 – Открытие файла электронной подписи

Рисунок 34 – Информация о подписи и сертификате

Далее рассмотрим, как будет выглядеть работа уровней иерархической архитектуры при отказе работы ее компонентов.

В качестве примера рассмотрим отзыв сертификата, выданного подчиненному удостоверяющему центру. Для этого перейдем в корневой удостоверяющий центр, выберем в оснастке «Центр сертификации» вкладку «Выданные сертификаты». Среди сертификатов выберем необходимый и в контекстном меню для него выберем задачу «Отзыв сертификата» (рисунок 35).

Рисунок 35 – Запуск процедуры отзыва сертификата

Появится окно отзыва сертификатов (рисунок 36), в котором необходимо указать причины, дату и время для отзыва сертификата. Для данного примера необходимо выбрать причину «Приостановка действий». Далее нам потребуется восстановить действие сертификата, а остальные варианты данную процедуру совершить не позволят.

Рисунок 36 – Параметры отзыва сертификата

Во вкладке «Отозванные сертификаты» присутствует только что отозванный сертификат, но информация об этом еще не опубликована. Чтобы это исправить нажмем правой кнопкой мыши в любом месте в данном разделе и выберем задачу «Публикация» (рисунок 37).

Рисунок 37 – Вызов процедуры публикации списка отозванных сертификатов

Появится окно выбора типа публикуемого списка отозванных сертификатов. Выберем «Новый базовый CRL» (рисунок 38). После этого отменим отозванный сертификат (рисунок 39)

Рисунок 38 – Вызов процедуры публикации списка отозванных сертификатов

Рисунок 39 – Отмена отзыва сертификата

23.Модели доверия уц. Мостовая модель.

Понятие доверия является в PKI краеугольным, то есть вся система с ключами и сертификатами работает в случае доверяя пользователей некой 3 доверенной стороне (УЦ). Поскольку Удостоверяющих Центров может быть больше 1, то схема их взаимодействия порождает различные модели доверия(иерархическая, сетевая,мостовая).

1. УЦ3 и УЦ5 проходят процедуру кросс-сертификации с мостовым УЦ, каждый из них получает себе сертификат УЦм и подписывает его своим закрытым ключом, а УЦм получает себе сертификаты УЦ3 и УЦ5 и подписывает их. (Кросс-сертификация – процесс установки доверит отношений между ранее не связанными УЦ. Он заключается в использовании кросс-сертификатов).
2. А проверяет сертификат УЦм с помощью обычного сертификата УЦ5, убеждаясь, что УЦм достоверный.
3. Используя сертификат УЦм, А проверяет подлинность кросс-сертификата УЦ3 и убеждается, что сертификат УЦ3 достоверный.
4. С помощью сертификата УЦ3 проверяется сертификат С.

24.Протокол tls/ssl. Уровень диалога (рукопожатия).

• Криптографическая безопасность: TLS должен использоваться для установления безопасного соединения между двумя участниками.
• Интероперабельность: независимые разработчики могут создавать приложения, которые будут взаимодействовать по протоколу TLS, что позволит устанавливать безопасные соединения.
• Расширяемость: TLS формирует общий каркас, в который могут быть встроены новые алгоритмы открытого ключа и симметричного шифрования.
• Отн эфф-ть: криптогр операции интенсивно используют ЦП, особенно операции с откр ключом. Для этого вводится понятие сессии, для кот опр-ся алг-мы и их пар-ры. В рамках 1 сессии м б создано неск соединений (например, ТСР).

1. Обмен сообщениями Hello для согл-я алг-мов, обмен случ знач-ми и проверка возобновл-ти сессии.
2. Обмен необходимыми криптограф пар-рами, кот позволяют клиенту и серверу согласовать премастер-секрет (клиент посылает премастер секрет серверу).
3. Обмен сертификатами и криптографической информацией, что позволяет клиенту и серверу аутентифицировать друг друга.
4. Предоставление параметров безопасности на уровень Записи.
5. Возможность клиенту и серверу проверить, что они вычислили одни и те же параметры безопасности и что Рукопожатие произошло без вмеш-ва злоум-ка.

Идентификатор сессии	Произвольная посл-ть байтов, выбираемая сервером для идентификации акт или возобновляемого состояния сессии
Серт-ат уч-ка	Х.509 v3 сертификат участника. Этот элемент м б нулевым
Метод сжатия	Алг-м, используемый для сжатия данных перед шифрованием
Набор алгоритмов	Алгоритм симметр шифр-я данных (null, DES и т.д.), МАС-алг-м (MD5 или SHA) и разл криптогр атрибуты
Мастер-секрет	48-байтный секрет, разделямый клиентом и сервером

Выбор архитектуры PKI

Любой тип архитектуры PKI имеет свои слабые и сильные стороны. Не существует архитектуры, совершенной для всех сред. Выбор оптимальной архитектуры осуществляется с учетом специфики деятельности, потребностей и возможностей организации [70].

Одиночный УЦ — простое и рациональное решение для небольшого однородного сообщества. Когда сообщество может договориться с одиночным УЦ о выпуске всех своих сертификатов, исчезают проблемы, связанные с построением и валидацией пути сертификации. Компрометация одиночного УЦ, безусловно, является катастрофой и делает недействительными все выпущенные им сертификаты. В результате сообщество полностью теряет доступ к сервисам безопасности. С другой стороны, такое сплоченное сообщество способно эффективно распространить уведомление о компрометации и быстро восстановить PKI.

Иерархическая PKI — это оптимальное решение для организации со строгой иерархической структурой. Иерархическая PKI соответствует структуре организации, поэтому центр определяется естественным образом. Построение и валидация пути сертификации — просты. Однако могут возникнуть трудности при наложении этой структуры на совокупность независимых удостоверяющих центров. Создание иерархической PKI лучше начинать с организации головного УЦ. Подчиненные удостоверяющие центры могут быть объединены в иерархию уже при развертывании, немедленно, без сложных проблем перехода. Компрометация головного УЦ выводит из строя всю инфраструктуру, но восстановить работу PKI после компрометации любого другого УЦ достаточно просто. Правильно выбранные политика, регламент функционирования и средства физической защиты УЦ могут сделать его компрометацию маловероятной.

Сетевая PKI — это, скорее, вынужденное, нежели оптимальное решение для тех организаций, которые не имеют четкой иерархической структуры. В таких организациях проще развернуть сетевую PKI, поскольку взаимодействующие стороны предпочитают устанавливать равноправные, а не подчиненные отношения доверия. Проблемы подчиненности могут вызывать разногласия и должны всесторонне обсуждаться, как это происходит при развертывании иерархической инфраструктуры. Если удостоверяющие центры были основаны несколькими подразделениями организации ранее, то наиболее простым решением будет сетевая PKI. Кроме того, сетевая PKI — лучший вариант, если организация нуждается в инфраструктуре, способной легко преодолевать последствия компрометации любого УЦ. Компрометация одного УЦ будет катастрофой только для его пользователей, но серьезно не отразится на транзакциях между пользователями других удостоверяющих центров сетевой PKI. Главные недостатки сетевой архитектуры PKI — сложность построения и валидации пути сертификации.

Списки доверия используются в тех случаях, когда невозможна кросс-сертификация между двумя инфраструктурами. Пользователи двух разных PKI не могут влиять на установление отношений кросс-сертификации между своими инфраструктурами, но могут применять списки доверия. Поддержка списков доверия позволяет им устанавливать между собой защищенную связь. Несмотря на многие ограничения, списки доверия являются решением, которое принимается самими пользователями. Поскольку многие организации пока не имеют собственных PKI, списки доверия — наиболее популярный способ устанавливать защищенные коммуникации между отдельными пользователями разных PKI.

Кросс-сертификация — простое решение для связывания небольшого числа корпоративных PKI. Оно эффективно, когда две организации имеют налаженные связи. Например, две компании, которые подписали договор о долговременном сотрудничестве или организации совместного предприятия, могут кросс-сертифицировать свои PKI. Однако такое решение неприемлемо в том случае, когда в совместную работу вовлечено множество сторон или деловые отношения развиваются динамично.

Мостовые удостоверяющие центры — эффективное решение для связывания большого числа разнородных корпоративных PKI. Эта модель наиболее соответствует современным динамичным деловым отношениям, когда компании работают с ограниченным набором деловых партнеров, но связи между ними быстро устанавливаются и легко разрываются. Отношения между компаниями одной отрасли меняются не столь быстро. Мостовой УЦ позволяет установить отдельную связь с каждой корпоративной PKI. Обеспечивая мост доверия со всеми корпоративными PKI, даже если они никогда не работали вместе, мостовой УЦ поддерживает динамичные деловые связи, необходимые современной экономике.

Читайте также

Обзор 64-разрядной архитектуры

Обзор 64-разрядной архитектуры С точки зрения программиста основная трудность при переходе от 32-разрядной модели к 64-разрядной заключается в том, что размер указателей и таких системных типов данных, как size_t и time_t, теперь может составлять 64 бита. Поэтому виртуальное

4.1. Особенности архитектуры

4.1. Особенности архитектуры Если раньше система реального времени рассматривалась нами как один процесс (с точки зрения ресурсов), то распределенные СРВ представляют уже набор взаимодействующих процессов. Специфика заключается в том, что отлаживаемое приложение может

API-ориентированные архитектуры

API-ориентированные архитектуры Учитывая недостатки процессоро-ориентированных архитектур, многие ISV, производители оборудования и организации по стандартизации совместно разрабатывали архитектуры, в основе которых лежит интерфейс прикладных программ API[ 8 ] (application

Расширения архитектуры PowerPC

Расширения архитектуры PowerPC Так как первое поколение процессоров PowerPC создавалось специально под AS/400 и не было PowerPC в полном смысле, мы решили дать этим процессорам новое название s PowerPC Optimized for the AS/400 Advanced Series, но так как это труднопроизносимо, решено было остановиться на

Обзор архитектуры MI

Обзор архитектуры MI Определение архитектуры MI не привязано к аппаратуре. Это не физический, а логический интерфейс системы. Как уже говорилось в главе 1, архитектура MI предлагает полный набор API для OS/400 и всех приложений. Этот набор полон по определению; то есть ни система,

1.11. 64-разрядные архитектуры

1.11. 64-разрядные архитектуры С середины до конца 90-х годов развивается тенденция к переходу на 64-разрядные архитектуры и 64-разрядное программное обеспечение. Одной из причин является более значительная по размеру адресация внутри процесса (например, 64-разрядные

Подходящая метафора для архитектуры убеждения

Подходящая метафора для архитектуры убеждения Не так давно было выпущено несколько книг, в которых можно выбрать концовку на свой вкус (например, «Игра в классики»[7] Хулио Кортасара). Автор предлагает «перейти на страницу 121», если считаете, что произойдет А, на страницу 84,

Глава 11 Ключевая часть архитектуры

Глава 11 Ключевая часть архитектуры Запуская браузер «Яндекса», Волож обозначил его предназначение так: для «реальных дорог», то есть в условиях плохо работающего мобильного Интернета.Подарок к своему пятнадцатилетнему юбилею «Яндекс» сотворил 1 октября 2012 г., предложив

Глава 11. Проектирование системной архитектуры

Глава 11. Проектирование системной архитектуры Потребность в архитектуреНа протяжении многих лет я слышала разные определения программной архитектуры: от «программная архитектура — это то, чем занимаются специалисты по программной архитектуре» до «программная

ОО-изменение архитектуры (re-architecturing)

ОО-изменение архитектуры (re-architecturing) Понятие внешней программы хорошо соответствует остальной части подхода. Основной вклад метода — архитектурный: объектная технология говорит, как разработать структуру систем, чтобы обеспечить расширяемость, надежность и повторное

6.1. ПОНЯТИЕ АРХИТЕКТУРЫ ПРОГРАММНОЙ СИСТЕМЫ

6.1. ПОНЯТИЕ АРХИТЕКТУРЫ ПРОГРАММНОЙ СИСТЕМЫ Разработка архитектуры системы — это процесс разбиения большой системы на более мелкие части. Для обозначения этих частей придумано множество названий: программы, компоненты, подсистемы…Процесс разработки архитектуры —

Основные понятия архитектуры PKI

Основные понятия архитектуры PKI Архитектура PKI описывает структуру отношений доверия между удостоверяющими центрами и другими субъектами инфраструктуры. По архитектуре PKI делятся на разные типы в зависимости от следующих характеристик:* количества удостоверяющих