По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Пайплайн CI/CD – это основа разработки программного обеспечения и один из основных компонентов конвейера DevOps. Процесс непрерывной интеграции/доставки (или развертывания) определяет ряд шагов, которые специалисты по программному обеспечению должны выполнить для создания новых программ.
Несмотря на то, что CI/CD повышает эффективность производства, этот процесс пренебрегает безопасностью. Базы данных, проприетарный код, учетные данные, ключи, учетные цифровые идентификационные данные и пароли, используемые в производственных и тестовых средах, также являются угрозой для безопасности.
Данная статья рассказывает о безопасности CI/CD, проблемах и рекомендациях по обеспечению безопасности производственного конвейера программного обеспечения.
Что такое безопасность CI/CD?
Безопасность CI/CD – это определенные шаги по защите конвейера автоматизированного производства программного обеспечения. И хотя общая безопасность производства программного обеспечения важна, линия доставки обновлений и устранений ошибок в программном обеспечении также должна быть надежной.
Пайплайн (или конвейер) CI/CD – это поток автоматической интеграции и доставки (или развертывания) приложений. Метод реализует обновления и исправления ошибок в соответствии с потребностями клиентов. Как итог, основное внимание уделяется полной автоматизации доставки программного обеспечения для непрерывного производства.
Однако в конвейере CI/CD упускается из виду его безопасность. Путем использования автоматизации тестирования и постоянного мониторинга администраторы безопасности должны проводить оценку уязвимостей на различных этапах разработки программного обеспечения.
Общие проблемы безопасности в конвейере CI/CD
Существует множество проблем безопасности, которые следует учитывать при защите конвейера CI/CD:
Серьезной проблемой является соблюдение требований к данным в непроизводственной среде. Чем больше людей работает над одним проектом, тем больше появляется возможных точек нарушения безопасности.
Необходимо выработать четко определенные правила контроля доступа и политики паролей для всех пользователей. В случае компрометации должен существовать заранее подготовленный план реагирования на различные инциденты.
Автоматизация и оркестровка занимают немалую часть программного обеспечения и для них требуются множество единичных фрагментов программного кода.
Быстро меняющаяся среда с постоянными обновлениями оставляет большой простор для различного рода инцидентов и непреднамеренных компрометаций. Лучшей политикой безопасности здесь будет встраивание безопасности непосредственно в конвейер.
Рекомендации по обеспечению безопасности конвейера CI/CD
Наилучшие методы обеспечения безопасности CI/CD зависят от инфраструктуры DevOps. Ниже приведены десять основных руководств по защите конвейера при работе в среде CI/CD.
1. Моделирование угроз безопасности
Проведите исследование в области потенциальных угроз безопасности. Определите точки, где необходимо обеспечить дополнительные уровни безопасности, попробуйте смоделировать эти угрозы и разработайте упражнения для повышения уровня информированности о потенциальных проблемах безопасности.
Большинство угроз безопасности находятся в точках стыковки. Все, что подключается к конвейеру, должно регулярно исправляться и обновляться. Блокируйте любые устройства, не соответствующие требованиям безопасности.
2. Проверка безопасности до фиксации
Проводите проверки безопасности до фиксации кода в системе контроля версий. Большинство IDE предоставляют подключаемые модули безопасности и предупреждают об уязвимостях кода по мере его ввода.
Проводите независимую оценку работ неопытных разработчиков перед отправкой кода в Git. Используйте небольшие фрагменты программного кода и список контрольных вопросов, чтобы убедиться в том, что код соответствует всем протоколам и стандартам безопасности. Помимо этого, избегайте копирования и публикации ключей API, токенов и других конфиденциальных данных.
3. Проверяйте зафиксированный код
После фиксации кода проверьте его еще раз, чтобы убедиться в том, что все в порядке. Используйте инструменты статистического анализа кода, чтобы получить отчет об ошибках. Инструменты анализа не требуют, чтобы приложение было запущено, а многие их них вместе с отчетом предоставляют полезные советы.
Отправьте отчеты о сканировании кода в службу безопасности, чтобы узнать, требуется ли какая-либо доработка. Используйте системы отслеживания ошибок и регистрируйте результаты, чтобы вы могли убедиться, что все ошибки исправлены. Кроме того, проанализируйте историю Git на предмет подозрительных действий.
4. Защитите свой Git
Git – это приоритетная цель для хакеров. Убедитесь в том, что разработчики осведомлены о том, как использовать Git, и постоянно информируются о действиях компании.
Используйте файл .gitignore, чтобы исключить случайную фиксацию стандартных и сгенерированных кэшированных файлов. Имейте локально сохраненную и защищенную резервную копию
5. Проверяйте наличие уязвимостей в библиотеках с открытым исходным кодом
Библиотеки с открытым исходным кодом – это важный компонент при создании приложений. Однако программное обеспечение сторонних разработчиков может быть подвержено изменениям кода, что может косвенно повлиять на безопасность вашего приложения.
Обязательно анализируйте и сканируйте пакеты с открытым исходным кодом на наличие известных проблем безопасности. Используйте инструменты анализа композиции программного обеспечения для анализа стороннего программного обеспечения, компонентов или файлов.
И в конце пометьте все выявленные проблемы, чтобы сохранить качество кода на максимальном уровне.
6. Автоматизируйте обеспечение безопасности с помощью IaC
Инфраструктура, представленная как код (IaC) обеспечивает согласованные условия разработки и тестирования. В отличие от ручной настройки среды инструменты IaC, такие как Ansible, Terraform или Puppet, помогают автоматически обеспечивать безопасность инфраструктуры.
Дополнительное преимущество заключается в том, что IaC безупречно работает в цепочке инструментов DevOps. Постоянное тестирование конфигураций многократного применения и обеспечение исполнения установленных процедур гарантируют отличные производственные результаты и высокое качество программного обеспечения.
7. Мониторинг приложения после развертывания
После развертывания приложения постоянно сканируйте его и контролируйте с целью предотвратить любые угрозы. Мониторинг помогает отслеживать и устранять подозрительную активность на основе предоставляемых данных.
Используйте такие инструменты, как Grafana или Kibana, для создания интерактивных визуальных информационных панелей, чтобы получать уведомления о любых подозрительных действиях.
8. Распределите задачи и создайте ролевую модель доступа
Наделение пользователей правами доступа может замедлить и даже помешать процессу тестирования. Тем не менее, установление и применение ролевой модели доступа для выполнения только основных задач имеет решающее значение с точки зрения безопасности.
Когда дело доходит до Git, определите роли доступа для каждого репозитория и установите двухфакторную аутентификацию для каждого зафиксированного участка кода. Попробуйте применить систему разделения задач, чтобы обеспечить безопасность конвейера, сохраняя при этом непрерывную доставку.
9. Храните персональные данные в безопасности
Защитите все персональные данные, которые обеспечивают доступ к программному обеспечению и службам, такие как токены API, пароли, ключи SSH, ключи шифрования и т.д. Ненадежная защита персональных данных может дать возможность хакерам «нанести удар», что может привести к утечке данных и краже интеллектуальной собственности.
Поэтому используйте платформу управления ключами защиты для безопасного и автоматизированного доступа к ключам. Программное обеспечение обеспечивает использование учетных цифровых идентификационных данных только при явном запросе. Для управления несколькими сложными паролями используйте соответствующее программное обеспечение для управления паролями.
10. Наводите порядок
В среде CI/CD все процессы и задачи протекают быстро и без надлежащей очистки. Обязательно закрывайте все временные ресурсы, такие как виртуальные машины, контейнеры или процессы. Помимо этого, обеспечьте надлежащую безопасность в целом и удалите лишние утилиты и инструменты.
Заключение
Безопасность конвейера CI/CD – это процесс, который меняется от системы к системе. В данной статье была представлена процедура обеспечения безопасности конвейера CI/CD.
Предыдущий материал из цикла про ARP в IPv4. Ждет вас по ссылке.
Как хост может узнать, следует ли пытаться отправить пакет хосту через сегмент, к которому он подключен, или отправить пакет на маршрутизатор для дальнейшей обработки? Если хост должен отправлять пакеты на маршрутизатор для дальнейшей обработки, как он может узнать, на какой маршрутизатор (если их несколько) отправлять трафик? Эти две проблемы вместе составляют проблему шлюза по умолчанию.
Для IPv4 проблему довольно легко решить, используя префикс и длину префикса. Рисунок ниже демонстрирует нам это.
Реализации IPv4 предполагают, что любой хост в пределах одной подсети IPv4 должен быть физически подключен к одному проводу. Как реализация может определить разницу? Маска подсети - это еще одна форма длины префикса, которая указывает, где заканчивается сетевой адрес и начинается адрес хоста. В этом случае предположим, что длина префикса равна 24 битам, или сетевой адрес равен /24. 24 указывает вам, сколько битов задано в маске подсети: 24 bits = 11111111.11111111.11111111.0000000
Поскольку в IPv4 используется десятичная запись маски, это также можно записать как 255.255.255.0. Чтобы определить, находится ли C на том же проводе, что и A, A будет:
Логическое умножение маски подсети с адресом локального интерфейса
Логическое умножение маски подсети с адресом назначения
Сравните два результата; если они совпадают, целевой хост находится на том же канале связи, что и локальный интерфейс
На рисунке ниже это продемонстрировано.
На рисунке выше показано четыре IPv4-адреса; предположим, что A должен отправлять пакеты в C, D и E. Если A знает, что длина префикса локального сегмента составляет 24 бита либо с помощью ручной настройки, либо с помощью DHCPv4, то он может просто посмотреть на 24 наиболее значимых бита каждого адреса, сравнить его с 24 наиболее значимыми битами своего собственного адреса и определить, находится ли пункт назначения на сегменте или нет. Двадцать четыре бита IPv4-адреса создают хороший разрыв между третьей и четвертой секциями адреса (каждая секция IPv4-адреса представляет собой 8 бит адресного пространства, в общей сложности 32 бита адресного пространства).
Любые два адреса с такими же левыми тремя секциями, что и у A, называемые сетевым адресом, находятся в одном сегменте; любой адрес, которого нет в сегменте. В этом случае сетевой адрес для A и C совпадает, поэтому A будет считать, что C находится в одном сегменте, и, следовательно, будет отправлять пакеты C напрямую, а не отправлять их на маршрутизатор. Для любого пункта назначения, который A считает вне сегмента, он будет отправлять пакеты на IPv4-адрес конечного пункта назначения, но на MAC-адрес шлюза по умолчанию. Это означает, что маршрутизатор, выступающий в качестве шлюза по умолчанию, примет пакет и переключит его на основе IPv4-адреса назначения. Как выбирается шлюз по умолчанию? Он либо настраивается вручную, либо включается в параметр DHCPv4.
А что насчет D? Поскольку сетевые части адресов не совпадают, A будет считать, что D находится вне сегмента. В этом случае A отправит любой трафик для D на свой шлюз по умолчанию, которым является B. Когда B получит эти пакеты, он поймет, что A и D достижимы через один и тот же интерфейс (на основе своей таблицы маршрутизации), поэтому он будет отправлять ICMP-перенаправление на A, говоря ему, что нужно отправлять трафик на D напрямую, а не через B.
IPv6 представляет собой более сложный набор проблем, которые необходимо решить при выборе шлюза по умолчанию, потому что IPv6 предполагает, что одно устройство может иметь много адресов IPv6, назначенных конкретному интерфейсу. Рисунок ниже демонстрирует это.
На рисунке выше предположим, что администратор сети настроил следующие политики:
Ни один хост не может подключаться к A, если у него нет адреса в диапазоне адресов 2001: db8: 3e8: 110 ::/64.
Ни один хост не может подключиться к D, если у него нет адреса в диапазоне адресов 2001: db8: 3e8: 112 ::/64.
Примечание: В реальном мире вы никогда не построили бы такую политику; это надуманная ситуация, чтобы проиллюстрировать проблему, поставленную в сети минимального размера. Гораздо более реальной проблемой такого же типа была бы одноадресная переадресация обратного пути (uRPF).
Чтобы эти политики работали, администратор назначил 110::3 и 112::12 хосту C и 111::120 хосту F. Это может показаться странным, но совершенно законно для одного сегмента иметь несколько подсетей IPv6, назначенных в IPv6; также совершенно законно иметь одно устройство с несколькими адресами. На самом деле, в IPv6 существует множество ситуаций, когда одному устройству может быть назначен диапазон адресов.
Однако с точки зрения длины префикса нет двух адресов, назначенных C или F, в одной подсети. Из-за этого IPv6 не полагается на длину префикса, чтобы определить, что находится в сегменте, а что нет. Вместо этого реализации IPv6 ведут таблицу всех подключенных хостов, используя запросы соседей, чтобы определить, что находится в сегменте, а что нет. Когда хост хочет отправить трафик из локального сегмента, он отправляет трафик на один из маршрутизаторов, о котором он узнал из объявлений маршрутизатора. Если маршрутизатор получает пакет, к которому, как он знает, другой маршрутизатор в сегменте имеет лучший маршрут (поскольку у маршрутизаторов есть таблицы маршрутизации, которые говорят им, какой путь выбрать к какому-либо конкретному месту назначения), маршрутизатор отправит сообщение перенаправления ICMPv6, сообщающее хосту использовать какой-либо другой маршрутизатор первого перехода для достижения пункта назначения.
В следующей статьей мы поговорим про пакетную коммутацию.
Транспортный уровень OSI (уровень 4) определяет несколько функций, наиболее важными из которых являются восстановление после ошибок и управление потоком. Точно так же протоколы транспортного уровня TCP / IP также реализуют те же типы функций. Обратите внимание, что и модель OSI, и модель TCP / IP называют этот уровень транспортным. Но, как обычно, когда речь идет о модели TCP / IP, имя и номер уровня основаны на OSI, поэтому любые протоколы транспортного уровня TCP / IP считаются протоколами уровня 4.
Ключевое различие между TCP и UDP заключается в том, что TCP предоставляет широкий спектр услуг приложениям, а UDP-нет. Например, маршрутизаторы отбрасывают пакеты по многим причинам, включая битовые ошибки, перегрузку и случаи, в которых не известны правильные маршруты. Известно, что большинство протоколов передачи данных замечают ошибки (процесс, называемый error detection), и затем отбрасывают кадры, которые имеют ошибки. TCP обеспечивает повторную передачу (error recovery) и помогает избежать перегрузки (управление потоком), в то время как UDP этого не делает. В результате многие прикладные протоколы предпочитают использовать TCP.
Разница между TCP и UDP в одном видео
Однако не думайте, что отсутствие служб у UDP делает UDP хуже TCP. Предоставляя меньше услуг, UDP требует меньше байтов в своем заголовке по сравнению с TCP, что приводит к меньшему количеству байтов служебных данных в сети. Программное обеспечение UDP не замедляет передачу данных в тех случаях, когда TCP может замедляться намеренно. Кроме того, некоторым приложениям, особенно сегодня, к передаче голоса по IP (VoIP) и видео по IP, не требуется восстановление после ошибок, поэтому они используют UDP. Итак, сегодня UDP также занимает важное место в сетях TCP / IP.
В таблице 1 перечислены основные функции, поддерживаемые TCP/UDP. Обратите внимание, что только первый элемент, указанный в таблице, поддерживается UDP, тогда как TCP поддерживаются все элементы в таблице.
Таблица № 1 Функции транспортного уровня TCP/IP
Функции
Описание
Мультиплексирование с использованием портов
Функция, которая позволяет принимающим хостам выбирать правильное приложение, для которого предназначены данные, на основе номера порта.
Восстановление после ошибок (надежность)
Процесс нумерации и подтверждения данных с помощью полей заголовка Sequence и Acknowledgment
Управление потоком с использованием окон
Процесс, использующий размеры окна для защиты буферного пространства и устройств маршрутизации от перегрузки трафиком.
Установление и завершение соединения
Процесс, используемый для инициализации номеров портов, а также полей Sequence и Acknowledgment.
Упорядоченная передача данных и сегментация данных
Непрерывный поток байтов от процесса верхнего уровня, который "сегментируется" для передачи и доставляется процессам верхнего уровня на принимающем устройстве с байтами в том же порядке
Далее описываются возможности TCP, а затем приводится краткое сравнение с UDP.
Transmission Control Protocol
Каждое приложение TCP / IP обычно выбирает использование TCP или UDP в зависимости от требований приложения. Например, TCP обеспечивает восстановление после ошибок, но для этого он потребляет больше полосы пропускания и использует больше циклов обработки. UDP не выполняет исправление ошибок, но требует меньшей пропускной способности и меньшего количества циклов обработки. Независимо от того, какой из этих двух протоколов транспортного уровня TCP / IP приложение выберет для использования, вы должны понимать основы работы каждого из этих протоколов транспортного уровня.
TCP, как определено в Request For Comments (RFC) 793, выполняет функции, перечисленные в таблице 1, через механизмы на конечных компьютерах. TCP полагается на IP для сквозной доставки данных, включая вопросы маршрутизации. Другими словами, TCP выполняет только часть функций, необходимых для доставки данных между приложениями. Кроме того, роль, которую он играет, направлена на предоставление услуг для приложений, установленных на конечных компьютерах. Независимо от того, находятся ли два компьютера в одном Ethernet или разделены всем Интернетом, TCP выполняет свои функции одинаково.
На рисунке 1 показаны поля заголовка TCP. Хотя вам не нужно запоминать названия полей или их расположение, оставшаяся часть этой лекции относится к нескольким полям, поэтому весь заголовок включен сюда для справки.
Сообщение, созданное TCP, которое начинается с заголовка TCP, за которым следуют данные приложения, называется сегментом TCP. В качестве альтернативы также может использоваться более общий термин PDU уровня 4 или L4PDU.
Мультиплексирование с использованием номеров портов TCP
И TCP, и UDP используют концепцию, называемую мультиплексированием. Поэтому этот подраздел начинается с объяснения мультиплексирования с TCP и UDP. После этого исследуются уникальные возможности TCP.
Мультиплексирование по TCP и UDP включает в себя процесс того, как компьютер думает при получении данных. На компьютере может быть запущено множество приложений, таких как веб-браузер, электронная почта или приложение Internet VoIP (например, Skype). Мультиплексирование TCP и UDP сообщает принимающему компьютеру, какому приложению передать полученные данные.
Определенные примеры помогут сделать очевидной необходимость мультиплексирования. Сеть из примера состоит из двух компьютеров, помеченных как Анна и Гриша. Анна использует написанное ею приложение для рассылки рекламных объявлений, которые появляются на экране Григория. Приложение отправляет Григорию новое объявление каждые 10 секунд. Анна использует второе приложение, чтобы отправить Грише деньги. Наконец, Анна использует веб-браузер для доступа к веб-серверу, который работает на компьютере Григория. Рекламное приложение и приложение для электронного перевода являются воображаемыми, только для этого примера. Веб-приложение работает так же, как и в реальной жизни.
На рисунке 2 показан пример сети, в которой Гриша запускает три приложения:
Рекламное приложение на основе UDP
Приложение для банковских переводов на основе TCP
Приложение веб-сервера TCP
Грише необходимо знать, в какое приложение передавать данные, но все три пакета поступают из одного и того же Ethernet и IP-адреса. Вы могли подумать, что Григорий может посмотреть, содержит ли пакет заголовок UDP или TCP, но, как вы видите на рисунке, два приложения (wire transfer и web) используют TCP.
TCP и UDP решают эту проблему, используя поле номера порта в заголовке TCP или UDP соответственно. Каждый из сегментов TCP и UDP Анны использует свой номер порта назначения, чтобы Григорий знал, какому приложению передать данные. На рисунке 3 показан пример.
Мультиплексирование основывается на концепции, называемой сокетом. Сокет состоит из трех частей:
IP-адрес
Транспортный протокол
Номер порта
Итак, для приложения веб-сервера Григория, сокет будет (10.1.1.2, TCP, порт 80), потому что по умолчанию веб-серверы используют хорошо известный порт 80. Когда веб-браузер Анны подключается к веб-серверу, Анна также использует сокет - возможно, такой: (10.1.1.1, TCP, 49160). Почему 49160? Что ж, Анне просто нужен номер порта, уникальный для Анны, поэтому Анна видит этот порт 49160.
Internet Assigned Numbers Authority (IANA), организация, которая управляет распределением IP-адресов во всем мире, и подразделяет диапазоны номеров портов на три основных диапазона. Первые два диапазона резервируют номера, которые IANA затем может назначить конкретным протоколам приложений через процесс приложения и проверки, а третья категория резервирует порты, которые будут динамически выделяться для клиентов, как в примере с портом 49160 в предыдущем абзаце. Имена и диапазоны номеров портов (более подробно описано в RFC 6335):
Хорошо известные (системные) порты: номера от 0 до 1023, присвоенные IANA, с более строгим процессом проверки для назначения новых портов, чем пользовательские порты.
Пользовательские (зарегистрированные) порты: номера от 1024 до 49151, присвоенные IANA с менее строгим процессом назначения новых портов по сравнению с хорошо известными портами.
Эфемерные (динамические, частные) порты: номера от 49152 до 65535, не назначены и не предназначены для динамического выделения и временного использования для клиентского приложения во время его работы.
На рисунке 4 показан пример, в котором используются три временных порта на пользовательском устройстве слева, а сервер справа использует два хорошо известных порта и один пользовательский порт. Компьютеры используют три приложения одновременно; следовательно, открыто три сокетных соединения. Поскольку сокет на одном компьютере должен быть уникальным, соединение между двумя сокетами должно идентифицировать уникальное соединение между двумя компьютерами. Эта уникальность означает, что вы можете использовать несколько приложений одновременно, разговаривая с приложениями, запущенными на одном или разных компьютерах. Мультиплексирование на основе сокетов гарантирует, что данные будут доставлены в нужные приложения.
Номера портов являются важной частью концепции сокетов. Серверы используют хорошо известные порты (или пользовательские порты), тогда как клиенты используют динамические порты. Приложения, которые предоставляют услуги, такие как FTP, Telnet и веб-серверы, открывают сокет, используя известный порт, и прослушивают запросы на подключение. Поскольку эти запросы на подключение от клиентов должны включать номера портов источника и назначения, номера портов, используемые серверами, должны быть известны заранее. Таким образом, каждая служба использует определенный хорошо известный номер порта или номер пользовательского порта. Как общеизвестные, так и пользовательские порты перечислены на www.iana.org/assignments/servicenames-port-numbers/service-names-port-numbers.txt.
На клиентских машинах, откуда исходят запросы, можно выделить любой локально неиспользуемый номер порта. В результате каждый клиент на одном и том же хосте использует другой номер порта, но сервер использует один и тот же номер порта для всех подключений. Например, 100 веб-браузеров на одном и том же хост-компьютере могут подключаться к веб-серверу, но веб-сервер со 100 подключенными к нему клиентами будет иметь только один сокет и, следовательно, только один номер порта (в данном случае порт 80). Сервер может определить, какие пакеты отправлены от какого из 100 клиентов, посмотрев на порт источника полученных сегментов TCP. Сервер может отправлять данные правильному веб-клиенту (браузеру), отправляя данные на тот же номер порта, который указан в качестве порта назначения. Комбинация сокетов источника и назначения позволяет всем участвующим хостам различать источник и назначение данных. Хотя в примере объясняется концепция использования 100 TCP-соединений, та же концепция нумерации портов применяется к сеансам UDP таким же образом.
Почитайте продолжение цикла про популярные приложения TCP/IP.