exam23 - stankin/inet-2022 GitHub Wiki

Билет 23

1. Понятие доверенной среды. Способы обеспечения доверия в интернете.

2. Применение методологии и инструментов DevOps в веб-разработке.

◀️ Реферат к вопросам экзамена по дисциплине Интернет-технологии 1 курса магистратуры ▶️

Выполнили: Уколов Александр ИДМ-22-02, Помазан Наталья ИДМ-22-01, Крупенко Илья ИДМ-22-03

Понятие доверенной среды. Способы обеспечения доверия в интернете.

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

При организации информационной защиты облачных инфраструктур от НСД необходимо организовать пространство для надежного и безопасного функционирования этих технологий — создать доверенную среду (доверенную вычислительную или программно-аппаратную среду). В рамках понятия «доверенности» предполагается, что есть некий объект—система или процесс (среда, окружение, платформа, сеанс, загрузка), в поведении которых пользователь облачных технологий полностью уверен. Это объект, которому пользователь может доверять на сто процентов. Ожидаемое поведение данного объекта всегда совпадает с реальным. Понятие основано на фразеологизме «корень доверия» — от английского Root of Trust (набор компонентов, которым можно доверять). Таким образом, «доверенность» — гарантированное, строгое соответствие актуальным требованиям в части информационной безопасности облачных технологий, в части надежности и функциональной устойчивости в условиях современного информационного противоборства, но, при соблюдении определенных условий технологической независимости. Доверенная система облачных технологий — система, которая использует доверенные аппаратные и программные средства для разграничения привилегий абонентов облачных инфраструктур и обеспечения одновременной обработки информации разной категории секретности группой пользователей без нарушения прав доступа.

Исходя из этого, можно сформулировать понятие «доверенная среда» (доверенная вычислительная или программно-аппаратная среда) облачных технологий. Это взаимоувязанная по времени и задачам совокупность систем и средств разграничения доступа, идентификации и аутентификации, межсетевых экранов, средств антивирусной защиты и криптографических стандартов. Она отвечает политике безопасности и создает защищенное «облачное пространство». Для формирования такой среды необходимо выполнение двух основных условий: первое — вся аппаратная часть облачных инфраструктур должна быть полностью досконально проверена и перепроверена или создана самостоятельно на отечественной элементной базе. Второе — все программные средства, созданные для работы на этом оборудовании, должны быть написаны самостоятельно либо тщательно, детально и «придирчиво» проверены.

Таким образом, доверенная среда облачных инфраструктур — некое информационно-техническое, киберфизическое пространство, сформированное на основе комплекса технических и организационных мер и способное обеспечить его участникам предсказуемый и безопасный результат информационного взаимодействия. Важно, что при этом степень доверенности среды определяется надежностью циркулирующего в ней и предоставляемого ею контента. В рамках доверенной среды (доверенной вычислительной среды) облачных инфраструктур используются модули доверенной загрузки и средства разграничения доступа с динамическим контролем целостности данных. Известно, что абсолютное большинство современных компьютеров и серверов, использующихся в облачных инфраструктурах, трудно, почти невозможно назвать доверенными. Всегда сохраняется потенциальная угроза доступа нарушителя к компьютерам и другим электронным устройствам облачных инфраструктур, к их программному обеспечению (ПО), используя предварительно созданные и «глубоко запрятанные» (в процессе создания облачных инфраструктур) программные и аппаратные искусственные уязвимости, «закладки». Такие «закладки» могут находится как на вычислительных устройствах, так и на устройствах памяти и ввода-вывода элементов и средств облачных инфраструктур [2].

Доверенная среда включает в себя:

Доверенное аппаратное обеспечение (элементная база отечественного производства и отечественные аппаратные средства защиты информации).
Доверенное программное обеспечение (проверенное или отечественное системное ПО, прикладное ПО и программные средства защиты от НСД).
Выверенные и апробированные политики безопасности.
Доверенные каналы передачи.
Доверенное окружение.
Пользователей облачных инфраструктур [2].

Способы обеспечения доверия в интернете:

SSL-сертификаты.
TLS-сертификаты.
Электронная подпись (ЭП).

Что такое SSL-сертификат?

SSL-сертификат – это цифровой сертификат, удостоверяющий подлинность веб-сайта и позволяющий использовать зашифрованное соединение. Аббревиатура SSL означает Secure Sockets Layer – протокол безопасности, создающий зашифрованное соединение между веб-сервером и веб-браузером.

Компаниям и организациям необходимо добавлять SSL-сертификаты на веб-сайты для защиты онлайн-транзакций и обеспечения конфиденциальности и безопасности клиентских данных.

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

С момента создания протокола SSL около 25 лет назад, он был доступен в нескольких версиях. При использовании каждой из этих версий в определенный момент возникали проблемы безопасности. Затем появилась обновленная переименованная версия протокола – TLS (Transport Layer Security), которая используется до сих пор [5].

Как работает SSL-сертификат?

Использование SSL гарантирует, что данные, передаваемые между пользователями и веб-сайтами или между двумя системами, невозможно прочитать сторонним лицам или системам. SSL использует алгоритмы для шифрования передаваемых данных, что не позволяет злоумышленникам считать их при передаче через зашифрованное соединение. Эти данные включают потенциально конфиденциальную информацию, такую как имена, адреса, номера кредитных карт и другие финансовые данные.

Процесс работает следующим образом:

Браузер или сервер пытается подключиться к веб-сайту (веб-серверу), защищенному с помощью SSL.
Браузер или сервер запрашивает идентификацию у веб-сервера.
В ответ веб-сервер отправляет браузеру или серверу копию своего SSL-сертификата.
Браузер или сервер проверяет, является ли этот SSL-сертификат доверенным. Если это так, он сообщает об этом веб-серверу.
Затем веб-сервер возвращает подтверждение с цифровой подписью и начинает сеанс, зашифрованный с использованием SSL.
Зашифрованные данные используются совместно браузером или сервером и веб-сервером.
Этот процесс иногда называют подтверждением SSL-соединения. Хотя по описанию этот процесс выглядит длительным, в реальности он занимает миллисекунды.

Если веб-сайт защищен SSL-сертификатом, в веб-адресе появляется аббревиатура HTTPS (безопасный протокол передачи гипертекста). Для сайтов без SSL-сертификата отображается аббревиатура HTTP, без буквы S, соответствующей Secure (безопасный). Также в адресной строке веб-адреса будет отображаться значок замка. Это свидетельствует о безопасности и обеспечивает уверенность посетителям веб-сайта.

Чтобы просмотреть сведения об SSL-сертификате, можно щелкнуть значок замка, расположенный на панели браузера. Данные, входящие в SSL-сертификат, обычно включают:

Доменное имя, для которого выпущен сертификат.
Лицо, организация или устройство, для которого выпущен сертификат.
Центр сертификации, выдавший сертификат.
Цифровая подпись центра сертификации.
Связанные поддомены.
Дата выдачи сертификата.
Срок действия сертификата.
Открытый ключ (закрытый ключ не раскрывается) [5].

Что такое TLS-сертификат?

Протокол защиты транспортного уровня (Transport Layer Security, TLS), как и его предшественник SSL, — криптографические протоколы, обеспечивающие защищённую передачу данных между узлами в сети Интернет. TLS и SSL используют асимметричное шифрование для аутентификации, симметричное шифрование для конфиденциальности и коды аутентичности сообщений для сохранения целостности сообщений.

Как работает TLS-сертификат?

TLS даёт возможность клиент-серверным приложениям осуществлять связь в сети таким образом, что нельзя производить прослушивание пакетов и осуществить несанкционированный доступ.

Так как большинство протоколов связи может быть использовано как с TLS (или SSL), так и без них, при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Это может быть достигнуто либо с помощью использования унифицированного номера порта, по которому соединение всегда устанавливается с использованием TLS, либо с использованием произвольного порта и специальной команды серверу со стороны клиента на переключение соединения на TLS с использованием специальных механизмов протокола). Как только клиент и сервер договорились об использовании TLS, им необходимо установить защищённое соединение. Это делается с помощью процедуры подтверждения связи. Во время этого процесса клиент и сервер принимают соглашение относительно различных параметров, необходимых для установки безопасного соединения.

Основные шаги процедуры создания защищённого сеанса связи:

Клиент подключается к серверу, поддерживающему TLS, и запрашивает защищённое соединение.
Клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций.
Сервер выбирает из списка, предоставленного клиентом, наиболее надёжные алгоритмы среди тех, которые поддерживаются сервером, и сообщает о своём выборе клиенту.
Сервер отправляет клиенту цифровой сертификат для собственной аутентификации. Обычно цифровой сертификат содержит имя сервера, имя удостоверяющего Центра сертификации и открытый ключ сервера.
Клиент, до начала передачи данных, проверяет валидность (аутентичность) полученного серверного сертификата относительно имеющихся у клиента корневых Сертификатов удостоверяющих центров (центров сертификации). Клиент также может проверить, не отозван ли серверный сертификат, связавшись с сервисом доверенного удостоверяющего центра.
Для шифрования сессии используется сеансовый ключ. Получение общего секретного сеансового ключа клиентом и сервером проводится по протоколу Диффи-Хеллмана. Существует исторический метод передачи сгенерированного клиентом секрета на сервер при помощи шифрования асимметричной криптосистемой RSA (используется ключ из сертификата сервера). Данный метод не рекомендован, но иногда продолжает встречаться на практике.

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

При возникновении проблем на некоторых из вышеуказанных шагов подтверждение связи может завершиться с ошибкой, а безопасное соединение не будет установлено [6].

Электронная подпись

Электронная подпись (ЭП) — это атрибут электронного документа, который позволяет установить авторство и неизменность после подписания. В зависимости от своего вида электронная подпись может быть полностью равнозначна рукописной и обеспечивает подписанным файлам юридическую силу.

Функции электронной подписи. Электронная подпись:

Идентифицирует автора.
Позволяет определить, вносились ли изменения в документ после его подписания (доступно не всем видам подписи).
Подтверждает юридическую силу подписанного документа (доступно не всем видам подписи) [7].

Как работает ЭП?

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

Подписание документа производится в несколько этапов:

Хеш документа шифруется с помощью закрытого ключа.
Полученная подпись добавляется к документу.
К документу прикрепляется сертификат проверки.

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

Применение методологии и инструментов DevOps в веб-разработке.

DevOps (Development and Operations) – это методология разработки софта. Её задача – сделать взаимодействие системных администраторов и программистов в команде слаженным.

Методология DevOps появилась в 2009 году как решение проблемы в коммуникации между программистами и системными администраторами, а также достаточно сложной схемы проектных работ, что существенно удлиняло разработку ПО.

Изначально термином DevOps называли исключительно подход к разработке ПО, но со временем так стали называть и профессию. Появились DevOps-инженеры, ключевая задача которых – настройка и поддержание софта в рабочем состоянии. Их цель – сделать так, чтобы автоматизации на каждом этапе было как можно больше. DevOps упрощает и ускоряет разработку [8].

DevOps — это командная работа (между сотрудниками, занимающимися разработкой, операциями и тестированием), нет единого инструмента «DevOps», это скорее набор (или «инструментальная цепочка DevOps»), состоящий из нескольких инструментов. Как правило, инструменты DevOps вписываются в одну или несколько из этих категорий, что отражает ключевые аспекты разработки и доставки программного обеспечения:

Code — разработка и анализ кода, инструменты контроля версий, слияние кода;
Build — инструменты непрерывной интеграции, статус сборки;
Test — инструменты непрерывного тестирования, которые обеспечивают обратную связь по бизнес-рискам;
Package — репозиторий артефактов, предварительная установка приложения;
Release — управление изменениями, официальное утверждение выпуска, автоматизация выпуска;
Configure — конфигурация и управление инфраструктурой, Инфраструктура как инструменты кода;
Monitor — мониторинг производительности приложений, опыт работы с конечным пользователем [1].

В чём трудности внедрения DevOps?

Microsoft и консалтинговая компания Sogeti провели исследование Enterprise DevOps Report 2020-21 об актуальной ситуации с внедрением DevOps. Аналитики проинтервьюировали специалистов, внедривших более 250 облачных и DevOps-инструментов, и определили шесть ключевых проблем, с которыми сталкиваются компании в рамках трансформации.

Управление продуктами. В большинстве случаев компании имеют в арсенале несколько DevOps-решений, их поддержкой занимаются разные бизнес-подразделения. Это усложняет процесс, делает его более дорогостоящим. Более того, формируется культура поощрения быстрых результатов, которые не всегда учитывают последствия действий.
Качество. К сожалению, не все компании понимают, как разрешить возникающие между несколькими командами DevOps противоречия и стандартизировать работу в соответствии с политиками компании.
Управление ИТ. Существующие внутри многих компаний модели управления сфокусированы лишь на эффективности и контроле затрат. Они плохо применяются к методологии DevOps, цель которой – создание ценного для клиента продукта и его быстрый вывод на рынок.
Удалённая работа и географически распределенные команды. Чтобы удаленная команда была продуктивной и высокоэффективной, нужно внедрять не только технологические, но и культурные DevOps-решения. Для организаций это по-прежнему нетривиальная задача.
Соответствие требованиям. Отдельная задача для бизнеса – соответствие требованиям регуляторов. Это касается не только внутренних регламентов, но внешних норм для рынка в целом.
Безопасность. Чтобы на ранних этапах избежать потенциальных ошибок, компаниям нужны четкая политика безопасности, автоматизация процессов и контроль на уровне топ-менеджмента. Всё это стоит больших денег [9].

Как решать проблемы?

Аналитики Microsoft и Sogeti предлагают следовать следующим подходам в проектной работе:

Переход от проектно-ориентированных к продукт-ориентированным моделям работы. Внедрение итеративного подхода в разработке, согласно которому все работы выполняются параллельно с непрерывным анализом промежуточных итогов и правок на всех этапах DevOps-проекта.
Применение концепции InnerSource. Компания формирует профессиональное сообщество, чьи участники практикуют Open Source, обмениваются инфраструктурой и компонентами для оптимизации работы сотрудников. При этом права на код остаются за бизнесом.
Использование облачных платформ, систем контроля версий и средств DevOps – это позволит распределенным командам работать слаженно.
Применение подхода Everything-as-Code. Специалисты обращаются со всеми частями системы как с кодом, а конфигурации сохраняются вместе с исходными данными в репозитории. Это позволяет совершенствовать продукт за счет обновления исходного кода [8].

Инструменты на DevOps можно разбить на следующие категории:

Разработка и сборка. Инструменты данной категории легко интегрируются с другими решениями и позволяют управлять сразу несколькими потоками событий. Выделяют три группы средств:
- управление данными (Data Management) с возможностью вносить правки в схему БД и поддерживать их в соответствии с версией приложения;
- непрерывная интеграция (CI): обязательна способность запускать сборки в изолированной контейнерной среде;
- система управления версиями (SCM), которая должна иметь идеальную поддержку для Git-решений, позволяющих сразу нескольким разработчикам отслеживать изменения в файлах.
Автоматизация тестирования. Спектр инструментов для автоматизированного тестирования невероятно широк – у каждого решения своя направленность и свои преимущества. Автотесты делятся на три типа:
- модульные, позволяют убедиться в исправности конкретных функций в рамках одного модуля ПО;
- интеграционные, помогают проверить ту функциональность продукта, которую нельзя сделать с помощью модульного теста;
- системные, нужны для проверки приложения в целом.
Непрерывная интеграция и развертывание приложений. Непрерывная интеграция – это методика загрузки кода в общий репозиторий с последующей проверкой. Это позволяет автоматически выявлять ошибки на ранних этапах проекта, когда их проще всего устранить, и максимально быстро внедрять новые функции. Благодаря такой интеграции специалисты будут в режиме реального времени получать непрерывную обратную связь в чате команды. Проверка кода с помощью запросов pull – это метод, требующий использования веток. Он помогает сократить их количество и размер, гарантирует тщательное тестирование без потери в скорости разработки.
Непрерывная обратная связь. В методику непрерывной обратной связи входят сбор и анализ данных NPS (индекс потребительской лояльности), отчёты о багах, регулярные опросы о причинах оттока пользователей, посты и комментарии в социальных сетях, обращения в службу поддержки и многое другое. В культуре DevOps важно, чтобы каждый участник команды мог иметь доступ к фидбеку, предоставляемому клиентами. Это помогает комплексно управлять процессом, особенно на этапах глубокого тестирования продукта.
Решения для совместной работы. DevOps влечет за собой изменения культуры внутри компании. Применение того или иного инструмента не изменит привычки моментально, но сильно поможет появлению и развитию новых способов взаимодействия в командах. К решениям для совместной работы относят системы для отслеживания задач, ведения документации. Несмотря на растущую конкуренцию на рынке подобных решений, безусловный лидер – Jira. Этот гибкий инструмент позволяет разработчикам управлять огромным количеством задач спринта и проектной работой в целом. Система доступна даже стартапам – команды используют бесплатную или недорогую версию. Более того, этот продукт быстро развивается, и бизнес выбирает его для создания собственных интеграций со всеми решениями, что конечно, повышает ценность инструмента [8].

Преимущества и недостатки методологии:

Преимущества DevOps:

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

Недостатки DevOps:

Специалисты DevOps должны разбираться в разработке, тестировании, развертывании и поддержке, но эти знания могут быть поверхностными.
DevOps – рабочая культура, которую нельзя реализовать, просто следуя жизненному циклу разработки программного обеспечения. Чтобы компания могла влиться в среду DevOps, ей необходимо постоянно соблюдать основные принципы методологии и стремиться к изменениям [9].

ИСТОЧНИКИ