Блог

По мере того, как цифровые организации масштабируются, использование непрерывной интеграции становится необходимым, чтобы идти в ногу со временем. Использование инструментов CI / CD с открытым исходным кодом, таких как Jenkins, облегчает создание и тестирование программного обеспечения. Таким образом, организации поддерживают высококачественные стандарты и быстро исправляют ошибки в течение более коротких циклов. Этот подход идет рука об руку с гибким тестированием QMetry.

QMetry Test Management для пользователей JIRA теперь может интегрироваться с Jenkins в непрерывную интеграцию для автоматизации сборок и тестов. В этой статье мы рассмотрим пример, как легко это сделать.

Многие организации используют Jenkins для непрерывной интеграции. В конце создания или развертывания сборки они хотели бы, чтобы выполнялся набор тестов  на последней развернутой сборке. В конечном итоге результаты тестирования должны вернуться в JIRA для анализа и отчетности. Важно создать тест в QMetry Test Management для JIRA с правильными тегами и параметрами. В этом примере мы продемонстрируем, как это можно сделать.

Пример использования непрерывной интеграции

Вы можете легко интегрировать Jenkins с QMetry Test Management для JIRA. Например, обновите  свойства системных переменных в  pom.xml, используя работу Jenkins.

1. Здесь мы используем проект maven на основе https://github.com/qmetry/automation-cucumber .
2. В xml- файле мы настроили плагин maven для отправки результата теста в QMetry Test Management для JIRA.
3. Системные переменные в xml- файле, которые динамически обновляются в результате процесса сборки.

Диаграмма процесса взаимодействия

Создание проекта Дженкинс

1. Создайте новый “Pipline” на сервере Jenkins.

2. Настройте свой проект. Добавьте параметры проекта и свой источник SCM, как показано ниже.

3. Теперь вам нужно создать файл Jenkins для автоматизации рабочего потока. В этом примере это наш файл Jenkins. https://github.com/qmetry/automation-cucumber/blob/master/Jenkinsfile

4. Нажмите ссылку «Создать с параметрами» на левой панели. Здесь вы можете увидеть все параметры, которые вы настроили.

5. Нажмите кнопку « Создать» , чтобы начать процесс сборки.

Внутренний процесс при запуске процесса сборки:

• Получения кода проекта GitHub.
• Обновление параметров, предоставленных пользователем в XML- файле с использованием Grunt.
• Проверьте проект автоматизации с помощью команды «mvn test».
• Результаты испытаний будут представлены экземпляру JIRA.

Появится следующий экран с различными статистическими данными.

Далее, наведите указатель мыши на статистику запуска и нажмите «Журналы».

Журналы сообщений откроются во всплывающем окне.

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

Наша компания предоставляет услуги по автоматизации процесса непрерывной доставки и интеграции, обращайтесь office@itfb.com.ua

Первостепенной целью злоумышленника получить доступ к любой системе пользователя в корпоративной сети. Методы для этого могут быть использованы различные (письма с вредоносным ПО, ссылки на сайты, обновления для определенного ПО и т.п). И быстрота их реализации зависит от стойкости информационной безопасности предприятия. Получив доступ к одной из систем далее сценарий разворачивается в последовательности реализации таких этапов:

• закрепление в системе;
• анализ безопасности системы и окружения;
• распространение.

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

Понимая принципы действия злоумышленника, специалисты информационной безопасности могут выявить и предотвратить проникновения.

Закрепление в корпоративной сети

При проникновении в корпоративную сеть взломщик первым делом загружает скрипты и файлы для сбора информации: какое ПО, файлы, связь с системами управления; утилиты для подбора паролей, взлома учетных данных, заражения ПК; далее идет анализ трафика и сетевое сканирование.

Для скрытия от админа и сотрудников ИБ, злоумышленники применяют различные простые и сложные методы “маскировки”:

• передача файлов идет стандартными протоколами, тем самым позволяя затеряться между данными пользователей
• разбитие файлов и передача их по частям
• шифрование
• скрытие данных в аудио или видео файлах

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

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

Анализ окружения

Анализ какое ПО установлено, версии, ОС, обновления, патчи, защита и т.п выполняется на всех этапах проникновения. Используя эту информацию взломщик планирует стратегию проникновения и необходимые утилиты для этого.

Для этого этапа вполне пригодны стандартные средства, установленные в ОС

• powershell, vbs, cmd для Windows;
• grep, bash,perl, python в Unix/Linux и Mac OS.

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

Распространение

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

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

Теперь Вы понимаете насколько важно обеспечить безопасность сети как от внешних угроз так и от возможных внутренних.

Обращайтесь за помощью, office@itfb.com.ua и наши специалисты помогут защитить корпоративную сеть и устранить уязвимости

JIRA Software – идеальный инструмент для планирования, контроля процесса и создания завершенного ПО в команде. Она работает на самых распространенных системах управления данными.  Нет ограничений и по операционным системам.

Продукты жира позволяют:

1. Планировать. Распределение обязанностей и задач по времени. Вместительная база пользовательской истории проектов.
2. Отслеживать. Анализ приоритетности работ с расстановкой акцентов и возможностью информирования исполнителей.
3. Выпускать. Создание ПО при доступности наиболее релевантной и свежей информации.
4. Создавать отчетность. По окончанию всего проекта или определенной фазы руководитель свободно формирует отчетность, тем самым повышая результативность исполнителей проекта онлайн.

Отличным способом решения обыденных задач и упрощением работы является интеграция JIRA с существующими приложениями компании. Другими словами, Вы можете создавать автоматические запросы, задачи или реакцию на любое действие в различных приложениях режиме реального времени. Интеграция осуществляется по-разному, в зависимости от типа интегрируемого ПО: могут внедряться новые данные, уровни доступа, реакция на проблемы и так далее.

Наиболее эффективна интеграция JIRA Software с такими приложениями:

• SharePoint;
• ActiveDirectory;
• MS Project;
• Outlook.

Преимущества integration JIRA Share Point:

1. Автоматическое обновление данных в фоновом режиме.
2. Возможность выбирать одностороннее или двухстороннее соединение.
3. Вам доступны все функции «внешнего списка».
4. Рабочие процессы и изменения можно использовать для принятия различных бизнес-решений через Share Point

Интеграция JIRA и Ms Project так же дает возможность получить ряд преимуществ:

1. Новая форма ведения проектов.
2. Ускоренный переход между фазами планирования и исполнения.
3. Актуальные данные о результатах реализации проекта.
4. Участники проекта всегда имеют актуальные задачи, которые доносит до конечного исполнителя именно JIRA.
5. Повышение личной эффективности за счет отображения статуса и обновлений по созданной задаче.

JIRA интеграция с AD

Управление базой данных пользователей с регламентом доступа так же можно полностью делегировать JIRA.

В этом случае:

1. Происходит полная синхронизация групп и пользователей.
2. Упрощается система аутентификации.
3. Автоматическая загрузка свойств пользователей.
4. Отображение информации о пользователях и их статусе в реальном времени.

Теперь об интеграции Outlook и JIRA.

Электронная почта – незаменимый инструмент в работе почти любой организации.  При интеграции этих двух ПО  результатом становится:

• Быстрая обработка электронных писем с уведомлением JIRA Software;
• Создание новых проблем с ПО или добавление комментариев к существующим.
• Передача информации разработчикам о новых ошибках в режиме реального времени.

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

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

Обратитесь к профессионалам, и Ваша работа будет доведена до автоматизма, office@itfb.com.ua

Всем привет. Эта мини-статься будет о том, как прикрутить SSO к продуктам Atlassian, в частности Jira, Confluence.

И так, что нам понадобится:

1. Jira/Confluence
2. Подключение к AD
3. Плагин от Kantega AS (Kantega Single Sign-on with Kerberos and SAML)

Первые два пункта пропустим, так как уже их рассматривали не однократно. Установку плагина тоже пропустим, так как она заключается в:

• Найти плагин через marketplace
• Установка плагина, путем нажатия на одну кнопку
• Получение ключа и его активация

По сути будут выполнены шаги:

1. Создать пользователя svc-sso-jira
2. Установить Password never expires
3. Включить Kerberos AES 128 bit encryption
4. Узнать реальное имя Jira( можно выполнить nslookup jira.test.local)
5. На сервере AD выполнить, но эта команда будет сформирована позже
   1. ktpass /princ HTTP/ jira.test.local@TEST.LOCAL /mapuser svc-sso-jira@TEST.LOCAL /crypto AES128-SHA1 /pass * /ptype KRB5_NT_PRINCIPAL /out C:\jira.test.local.keytab
6. Положить jira.test.local.keytab в удобное место

Должно получится приблизительно следующее

Теперь переходим в сам плагин и начинаем его настраивать.

Настраивать будем через Kerberos и на примере Jira.

Выбираем Run setup wizard и следуем подсказкам. Указываем домен, пользователя, пароль, Canonical name, Realm name, Account name, метод шифрования(рекомендую остановится на AES 128), после чего будет сформирована инструкция, что, как и где надо выполнить. Имею ввиду команды от администратора.

После того, как будет сформирован файл jira.test.local.keytab, загрузить его через форму и приступить к тесту

Скорее всего будет ошибка, которая устраняется довольно легко, но может состоять из двух составляющих:

[sociallocker]

1. Необходимо добавить домен jira в список доверенных
   1. Для FF следует ввести в адресной строке about:config
   2. Найти negotiate-auth.trusted-uris и указать домен jira .yourdomain.com

2. Если ошибка не ушла, то следует проверить размер принимаемых заголовков и версию протокола HTTP в настройках сервера server.xml

Ну а поскольку имея AD, можно применить групповую политику, то думаю, вряд ли кому-то захочется обходить все учетки и прописывать руками. Пользуемся хромиумом…

[/sociallocker]

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

На этом, настройка завершена и можно приступать к тестам. Заходим под учеткой на ПК и открываем в браузере адрес jira. И видим, как мы уже авторизованы под своей учеткой в jira

Хотите прозрачную авторизацию для jira? Обращайтесь office@itfb.com.ua мы настроим.

Проект Prometheus представляет собой централизированную систему мониторинга, предлагает исходные тексты, бинарники под разные архитектуры (для основных компонентов) и Docker-образ. В документации приведены ссылки на код Ansible, Chef, Puppet и SaltStack. В репозиториях основных дистрибутивов уже есть пакеты с некоторыми компонентами, правда, их версия не самая актуальная. В Ubuntu на сегодня в репозитории доступна версия 0.16.2 сборки годичной давности, когда на сайте уже давно 1.5.2. Версии отличаются некоторыми параметрами конфигурационного файла и данными, записываемыми в метрики, поэтому, наверное, лучше сразу ставить последний релиз. Скачиваем архив:

$ wget -c https://github.com/prometheus/prometheus/releases/download/v1.5.2/prometheus-1.5.2.linux-amd64.tar.gz

Распаковываем и копируем файлы prometheus и promtool в /usr/bin, а шаблон конфигурационного файла в /etc/ prometheus. Также нужно создать каталог, куда будут складываться метрики /var/lib/prometheus/metrics. Создаем файл для запуска через systemd.

$ sudo nano /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network-online.target
[Service]
User=prometheus
Restart=on-failure
ExecStart=/usr/bin/prometheus
\ -config.file=/etc/prometheus/prometheus.yml
\ -storage.local.path=/var/lib/prometheus/metrics
[Install]
WantedBy=multi-user.target

Включаем в автозапуск и стартуем.

$ sudo systemctl daemon-reload
$ sudo systemctl enable prometheus

Аналогично проделываем с пакетом Node Exporter – для мониторинга самого сервера Prometheus он отлично подходит – и другими приложениями, если не принято решение использовать Telegram (о нем дальше).

В принципе можно даже попробовать запустить. Сервис Node Exporter будет запущен на порту 9100 и веб-интерфейс Prometheus на 9090 без какой-либо аутентификации и виден всем. Для защиты веб-интерфейса лучше установить при помощи параметра web.listen-address на localhost и указать пароль при помощи auth.user и auth.pass. Удобнее для этой цели использовать прокси, вроде nginx proxy_pass с htpasswd. Если не нравится, что метрики могут видеть все, то можно для их доставки на сервер Prometheus использовать VPN или SSH.

Конфигурационный файл называется /etc/prometheus/ prometheus.yml, после установки имеем рабочий шаблон с минимумом настроек, для мониторинга локальной системы его можно взять за основу. Для наших задач его достаточно. Файл в YAML-формате, все установки и значения по умолчанию можно узнать, введя prometheus -h. В Git в config/testdata/conf.good.yml есть более полный вариант, в котором найдете примеры установки TLS, подключение к Azure, AWS и другое.

Самыми важными для подключения агентов являются секции scrape_configs и static_configs:

scrape_configs:
- job_name: 'node'
scrape_interval: 5s
scrape_timeout: 10s
static_configs:
- targets: ['localhost:9090']
labels: {'host': 'prometheus'}

В терминах Prometheus targets это любой источник данных, называемый еще instance. Пока у нас один узел. При появлении следующего просто добавляем его данные – ip, порт и прочие параметры. Метка не обязательна, она позволяет переопределить имя узла, да и читать такой файл потом легче. Параметр job_name – это имя процесса, позволяющего группировать targets одного типа и задавать специфические

В файле можно определить несколько имен. Вся эта информация доступна в базе Prometheus, и ее можно использовать в фильтрах для отбора данных. Можем запустить в консоли и проверить работу и отсутствие ошибок (YAML все-таки).

$ promtool check-config /etc/prometheus/prometheus.yml

И первый раз запускаем в консоли, чтобы видеть появившиеся ошибки:

$ prometheus -config.file /etc/prometheus/prometheus.yml

Если все нормально, стартуем.

 

$ sudo systemctl start prometheus 
$ sudo systemctl status prometheus

Проверить работу Node Exporter можно, подключившись браузером к http://server_ip:9100/metrics, в результате должны получить список метрик.

Подключившись браузером на localhost:9090, можем увидеть информацию о работе Prometheus и просмотреть собранные метрики. Настройки, конфигурационный файл и статус удаленных узлов выводятся во вкладке Status (см. рис. 2).

Рисунок 2. Статус подключенных узлов в Prometheus

В Consoles и Graph генерируются графики. Принцип прост: начинаем вводить название метки, дальше интерфейс сам подскажет. Внизу будут выведены метки, попавшие под шаблон, используя эту информацию можно изменить запрос. Когда команда создана, нажимаем Execute. Результат будет выведен в виде числового ряда или графика (см. рис. 3).

Есть еще одна вкладка Consoles, на которой доступны графики и различная статистика по серверу, собранная Node Exporter (при необходимости шаблоны можно перестроить на Telegraf). Чтобы ее увидеть, нужно скопировать в /etc/prometheus два каталога из Git. В consoles лежат собственно шаблоны, в consoles_libraries – библиотеки. Текущие шаблоны настроены на job_name: node, prometheus, haproxy, cloudwatch, cassandra и blackbox.

Итак, сервер у нас готов принимать метрики. Но клиентов, кроме локального, пока нет.

Нужна установка мониторинга? Обращайтесь office@itfb.com.ua

Источник: Системный администратор №5 2017

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

Условно, все варианты взломов можно разделить на 3 основные группы:

1. Атаки на сайт

• Через веб (поиск уязвимостей в CMS, плагинах, доработках)
• Через брутфорс;

2. Через обслуживание IT инфраструктуры

• Закладки;
• Nulled-плагины/шаблоны:
• Утечка данных для доступа;
• Недоработки в сфере инженерии;

3. Через хостинг серверов

• Взлом через «соседей» по серверу;
• Брутфорс FTP/SSH/панели
• Перехват доступа.

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

Не редко с целью экономии компания делегирует полномочия по управлению веб-ресурса либо собственному ИТ-отделу, либо отдельно нанятому сотруднику. В этом случае очень сложно получить полноценную поддержку. Причина в том, что для отдельного программиста объем работы становится просто не охватываемым: сложно контролировать все процессы в одном лице. Если говорить об отделе ИТ, то в их полномочия входят еще и другие задачи, что осложняет мгновенное реагирование на появившуюся угрозу.

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

В  таком сотрудничестве с ИТ аутсорсерами есть ряд плюсов:

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

Следует всегда  помнить, что на безопасности нельзя экономить, ведь это в Ваших интересах. Доверьте поддержку ИТ инфраструктуры и обеспечение её безопасности профессионалам, обращайтесь office@itfb.com.ua

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

1. Почему сайты заражаются вирусами?

Определение причин, в результате которых происходит заражение web-ресурса кодами-вирусами, поможет в его дальнейшей очистке. Наиболее часто диагностируемые:

• уязвимые места:

– в скриптах;

– в шаблонах, плагинах (особенно это касается нелицензионных версий, либо их бесплатных аналогов с уже имеющимися хакерскими вредоносными сюрпризами – веб-шелл, бэкдор и т.д.);

• простые пароли от админ-панели или брутфорс-атака;
• перехват доступа при подключении по FTP (чаще всего из-за незащищенности каналов);
• взломанный сервер того хостинга, где размещается web-ресурс.

Если владелец зараженного сайта не поспешит его очистить от вирусов, то последствия будут весьма плачевными.

2. Что произойдет, если не лечить сайт от вирусов?

Зараженный web-ресурс сразу же определят антивирусные системы и Интернет-поисковики, что может привести к следующим действиям:

• блокирование поисковыми Интернет-системами, хостингом;
• пометка об угрозе безопасности компьютеру;
• пометка о нежелательности посещения данного сайта.

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

3. Как очистить сайт от вирусов: этапы лечения

Специалисты, которые профессионально занимаются избавлением сайтов от вредоносных кодов, дают ряд полезных советов. Что же делать непрофессионалу, если его web-ресурс подвергся такому нападению? Залог успеха кроется в комплексном подходе к решению этой проблемы.

• Проверить компьютер с помощью антивирусной коммерческой программы, базы которой находятся в регулярном обновлении (для определения размещения кода-вируса).
• Изменить все действующие пароли для доступа к хостинг-панели, админ-панели, от FTP (для закрытия уязвимостей веб-ресурса).
• Вылечить веб-ресурс – удалить из шаблонов, скриптов код-вирус.
• Предпринять меры защиты сайта – укрепить безопасность скриптов, сервера, регулярно делать бэкап сервера на компьютер локального типа, заказать аудит безопасности у специалистов.

Если самостоятельно выполнить перечисленные действия затруднительно, то следует незамедлительно обратиться за помощью в специализированную компанию, обращайтесь office@itfb.com.ua

Информация – самый ценный актив компании, который охватывает клиентскую базу, финансовые операции, персональные данные и другие стратегически важные данные.  Угроза утечки ценной информации может исходить как извне (например, от деятельности хакеров), так и изнутри компании от намеренных или же непреднамеренных действий сотрудников.

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

Защитить конфиденциальные данные от утечки по различным каналам передачи данным помогают DLP-системы. Обозначение DLP – это сокращение от «Data Loss Prevention», т.е. «предотвращение потери данных».

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

Возможные каналы утечки данных, контролируемые системами DLP:

• Рабочие станции – локальные диски, съемные носители, печать, факс, скриншот, буфер обмена.
• Системы хранения – файловые серверы, корпоративный портал, базы данных.
• Интернет – электронная почта, веб-ресурсы, социальные сети, системы мгновенного обмена информацией.

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

• Отслеживание авторизации в корпоративных ИТ-системах.
• Контроль подключения внешних жестких дисков и флешек с теневым копированием документов, передаваемых на них.
• Перехват и блокировка сетевых протоколов.
• Мониторинг печати документов на локальных и сетевых принтерах.
• Передача информации по Wi‑Fi и Bluetooth.

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

Агенты DLP-систем могут работать как в активном, видимом для пользователя режиме, так и в фоновом режиме, когда передача конфиденциальных данных не блокируется, но при этом о каждом таком событии оповещается администратор системы.

Внедрение системы DLP позволяет:

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

Услуги по выбору и внедрению DLP систем, обращайтесь, office@itfb.com.ua или в раздел Контакты.

Какие основные этапы следует выполнить, чтобы CI/CD-цепочка для разработки ПО работала? И как современные разработчики используют для этого бесплатные облачные сервисы? Чтобы ответить на все эти вопросы, необходимо рассмотреть поэтапную инструкцию, разработанную специально от компьютера до облачного сервиса.

• Этап №1 – создание генератора CI/CD-фраз. Например пишется на Python – создаются несколько директорий – ‘cicd-buzz’, ‘buzz’, файлов – ‘generator.py’, ‘init.py’. Последним шагом этого этапа будет выполнение скрипта в директории ‘buzz’.

• Этап №2 – создание автоматизированных тестов. Чтобы разместить unit-тесты, создается папка ‘tests’ в корневой директории с файлом ‘test_generator.py’. В нем сохраняется соответствующий код. А сами тесты из этого файла запускаются с помощью фреймворка ‘pytest’. Python Virtual Environment устанавливается заранее.

• Этап №3 – размещение кодов на веб-сервисе GitHub. Здесь создается репозиторий ‘cicd-buzz’, а файл ‘.gitignore’ – в корневой директории. После чего локально инициализируется Git, с последующей его отправкой на данный веб-сервис.

• Этап №4 – подключение Travis CI.

1. Выполняется вход на этот сервис с использованием учетных данных с GitHub.
2. Включается сборка по каждому из запросов репозитория.

Сборка кода (тестирование) начинается, как только завершиться активация в Travis.

• Этап №5 – добавление облачного сервиса Better Code Hub. Данный сервис позволит:

1. проверить качество кода;
2. контролировать результаты разработки;
3. получать информацию об угрозах для качества кода.

Его «плюс» в том, что он может интегрироваться с GitHub и Travis.

• Этап №6 – обучение buzz-генератора приему HTTP-запросов, выводу HTML. Последующие этапы нужны для развертывания кода, который уже прошел тестирование. Обертку для buzz-генератора можно сделать на Python Flask, после чего запустить веб-приложение. Теперь оба облачных сервиса займутся проверкой кода.↓

• Этап №7 – контейнеризация веб-приложения. Контейнер с легкой разверткой можно сделать при помощи Doker. Полученный Doker-образ веб-приложения будет при запуске контейнера собираться и запускаться.

• Этап №8 – публикация на Doker Hub. Этот этап поможет упростить развертку контейнеров в разных окружениях, с возможностью отката до предыдущих версий. Понадобиться создать зарегистрироваться на открытой платформе, предназначенной для сборки специализированных контейнерных систем – doker.com.

• Этап №9 – веб-приложения на Heroky. На этой платформе можно размещать масштабируемые веб-приложения после процедуры регистрации. Так появится возможность автоматизации процесса развертки каждой сборки ветки проекта, а настройку CI/CD-цепочки можно считать завершенной.

Обратите внимание: последние четыре этапа включают в себя добавление коммита с последующей отправкой изменений на GitHub.

Необходимо внедрение CI-CD инструментов для разработки, тестирования и внедрения, обращайтесь office@itfb.com.ua