По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Система доменных имен (DNS – Domain Name System) обеспечивает сетевую коммуникацию. DNS может показаться какой-то невидимой силой или сущностью до тех пор, пока что-то пойдет не так, потому что если DNS выйдет из строя, то ничего работать не будет. В данной статье будут рассмотрены передовые методы и наиболее важные меры безопасности для поддержания работоспособности вашей инфраструктуры DNS. Чтобы создать безопасную и надежную DNS, обязательно изучите перечисленные ниже пункты. Передовые технологии для обеспечения высокой производительности DNS Обеспечение избыточности и высокой доступности DNS DNS является основой сетевых приложений, поэтому инфраструктура DNS должна быть высоко доступной. А чтобы обеспечить необходимый уровень избыточности, в вашей организации должно быть, как минимум, два DNS-сервера, первичный и вторичный. Чтобы обеспечить работу критически важных для бизнеса систем, необходимо иметь, как минимум, два внутренних DNS-сервера. Все системы активного каталога, обмена данными и электронной почты полагаются на корректную работу DNS. Без исправно функционирующих внутренних DNS-серверов внутренние устройства не будут иметь возможности обмениваться данными. Если на одном DNS-сервере возникнет проблема, то второй сразу же заменяет его. Администраторы настраивают оборудование так, чтобы автоматически использовался вторичный DNS, если первичный не отвечает. IP-адрес внутреннего DNS-сервера может быть любым в диапазоне IP-адресов частной сети. Обеспечивая избыточность DNS-серверов, вы можете добиться высокой доступности инфраструктуры DNS. Непрерывная репликация с первичных серверов на вторичные обеспечит синхронизацию ваших DNS-записей и защитит систему от сбоев. Вы можете быть уверены в том, что конечный пользователь всегда будет иметь возможность получить доступ к системам. Сокрытие DNS-серверов и DNS-информации Не каждый DNS-сервер и не каждая информация должна быть доступна для всех пользователей. Во-первых, откройте только те серверы и данные, которые необходимы лицам, непосредственно использующим эти серверы. Это особенно важно, если ваши доменные имена являются общедоступными. Во-вторых, скройте свой основной DNS-сервер. Внешние пользователи не должны видеть первичные серверы. Записи для этих серверов не должны быть видны ни в одной общедоступной базе данных серверов имен. Запросы от пользователей должны обрабатывать только вторичные DNS-серверы. Если DNS-сервер доступен за пределами вашей сети, то это должен быть авторитативный DNS-сервер. Внешним пользователям не нужно обращаться к вашим рекурсивным DNS-серверам. Системная конфигурация будет высокопроизводительной только тогда, когда сервер будет отвечать только на итеративные запросы для соответствующих зон, за которые он отвечает. В довершение ко всему, иметь доступ к первичным серверам должны только системные администраторы и IT-персонал вашей организации. Если ваши первичные DNS-серверы будут открыты для всех внутренних пользователей, то это может создать серьезную угрозу для безопасности. Как показывает практика, лучше скрывать DNS-серверы и некоторые данные от пользователей, которым доступ к ним не нужен. Нужно ли использовать внешний или внутренний DNS-сервер? Ответ на данный вопрос зависит от внутренней настройки. Чтобы устройства в одном домене могли общаться друг с другом, вам необходимо указать внутренний DNS-сервер. Внешние DNS-серверы не могут работать с именами хостов внутренних устройств. Например, когда компьютер DESKTOP1 отправляет DNS-запрос для офисного принтера или сервера hr-1, только внутренняя DNS может предоставить запись ресурса. Если вы настроите устройство на использование внешнего DNS, например, 8.8.8.8 Google, то вы не сможете использовать внутренние ресурсы. Во внутренних средах необходимо установить, как первичный, так и вторичный DNS на внутренний сервер имен. Даже если основной DNS-сервер даст сбой, проблем с подключением не будет. Дополнительный DNS-сервер содержит все записи и действует как резервная копия. В случае возникновения какой-либо проблемы, этот сервер отвечает на все запросы до тех пор, пока не заработает основной сервер. Использование локального или ближайшего DNS-сервера Офисы крупных организаций часто расположены по всему миру. В таком случае следует настроить локальный DNS-сервер в каждом офисе, если позволяет инфраструктура. А все потому, что локальный сервер сокращает время ответа на DNS-запросы. Если же запрос проходит через глобальную сеть к удаленному серверу имен, то время загрузки увеличивается. При большом количестве клиентов, естественно, увеличивается количество DNS-запросов. Одна централизованная группа DNS-серверов, конечно, может обрабатывать все эти запросы, но с большой задержкой. Если компьютеры пользователей будут направляться на локальный или ближайший сервер имен, то время отклика может существенно сократиться. В таком случае задержка не превышает 50 мс. Более того, это значение обычно даже намного ниже. Использование ближайшего DNS-сервера сокращает время загрузки для всех устройств. Таким образом, вы также уменьшаете нагрузку на удаленный сервер в штаб-квартире и повышаете его производительность. Здесь также остается актуальной рекомендация иметь, как минимум, два DNS-сервера. Передовые методы обеспечения безопасности DNS DNS-серверы очень часто становятся целью кибератак. Важным шагом в предотвращении вторжений в вашу организацию является защита инфраструктуры DNS. Чтобы избежать серьезного нарушения настроек DNS, обязательно изучите меры безопасности, описанные ниже. Ведение журнала DNS-сервера Ведение журнала DNS-сервера – это один из самых эффективных способов отслеживания активности DNS. Журналы сообщают вам, если кто-то пытается вмешаться в ваши DNS-серверы. Помимо активности пользователей, журналы отладки сообщают вам о проблемах с DNS-запросами или обновлениями. Журналы DNS также показывают следы отравления кэша. При таком виде атаки злоумышленник изменяет хранящиеся в кэше данные и сбивают пользователей с курса. Например, IP-адрес www.youtube.com может быть заменен на IP-адрес вредоносного сайта. Когда пользователь отправляет запрос в DNS для youtube.com, сервер теперь возвращает неверный IP-адрес. В результате чего пользователи попадают на тот веб-сайт, который они не хотели посещать и становятся мишенью для хакеров. Несмотря на то, что ведение журнала отладки DNS повышает уровень безопасности, некоторые системные администраторы решают этим пренебречь. Основная причина такого решения – повышение производительности. Отслеживание сетевой активности может помочь вам обнаружить некоторые атаки, такие как DDoS, но не отравление кэша. Поэтому мы настоятельно рекомендуем использовать ведение журналов отладки DNS. Блокировка кэша DNS Всякий раз, когда появляется запрос от клиента, DNS находит информацию и сохраняет ее в кэше для будущего использования. Этот процесс позволяет серверу быстрее отвечать на одни и те же запросы. Злоумышленники могут воспользоваться этой функцией путем изменения сохраненной информации. Следующий шаг после использования журналов отладки DNS – это блокировка кэша DNS. Это функция определяет, когда кэшированные данные могут быть изменены. Сервер хранит информацию о поиске в течение времени, определяемого TTL (Time To Life - время жизни). Если блокировка кэша не используется, то информация может быть перезаписана до истечения TTL. Это оставляет место для атак с отравлением кэша. В некоторых операционных системах блокировка кэша может быть включена по умолчанию. Масштаб блокировки кэша может достигать 100%. Когда установлено значение 70, то перезапись данных невозможна до истечения 70% TTL. При определении блокировки кэша равным 100 изменение кэшированной информации блокируется до истечения всего TTL. Фильтрация DNS-запросов для блокировки вредоносных доменов Фильтрация DNS – это эффективный способ ограничить доступ пользователей к веб-сайту или домену. Основная причина для блокировки разрешения имен для домена – наличие информации о вредоносности этого домена. Когда клиент отправляет запрос на заблокированный веб-сайт, DNS-сервер прекращает любую связь между ними. DNS-фильтрация значительно снижает вероятность проникновения вирусов и вредоносных программ в вашу сеть. Когда пользователь не может получить доступ к вредоносной странице, то и количество угроз, которые могут проникнуть в вашу инфраструктуру, крайне мало. Таким образом, вашему IT-персоналу не требуется круглосуточно работать, чтобы очищать систему от вирусов. Помимо соображений безопасности, есть еще одна причина, по которой организации могут заблокировать домен – бизнес-политика или по соображениям производительности. В список заблокированных доменов могут входить социальные сети, азартные игры, порнография, страницы потокового видео или любые другие веб-сайты. DNS может фильтровать запросы по пользователю, группе или блокировать доступ для всех пользователей. Современные системы обеспечения защиты ПО и брандмауэры имеют DNS-фильтрацию в стандартной комплектации. Некоторые из них предоставляют списки плохих доменов, которые регулярно обновляются. Вы можете использовать готовое программное решение и таким образом автоматизировать фильтрацию DNS, а не добавлять новые записи вручную. Проверка целостности данных DNS с помощью DNSSEC Модули безопасности службы доменных имен (DNSSEC – Domain Name System Security Extensions) гарантируют, что пользователи получат действительные ответы на свои запросы. Целостность данных достигается за счет цифровой подписи DNSSEC на данных DNS, предоставляемых серверам имен. Когда конечный пользователь отправляет запрос, DNS-сервер предоставляет цифровую подпись с ответом. Стало быть, пользователи знают, что они получили достоверную информацию в качестве ответа на отправленный ими запрос. Этот дополнительный уровень безопасности помогает бороться с атаками на протокол DNS. Атаки «спуфинга» DNS и отравления кэша успешно предотвращаются, поскольку DNSSEC обеспечивает целостность данных и авторизацию их источника. В дальнейшем пользователи будут уверены, что посещают именно те страницы, которые хотели посетить. Настройка списков контроля доступа Списки контроля доступа (ACL – Access Control Lists) – это еще один способ защиты DNS-серверов от несанкционированного доступа и атак «спуфинга». К вашему основному DNS-серверу доступ должны иметь только системные и IT-администраторы. Настройка ACL для разрешения входящих подключений к серверу имен с определенных хостов гарантирует то, что только определенная часть персонала сможет обращаться к вашим серверам. Кроме того, ACL должны определять, какие серверы могут выполнять передачу зон. Злоумышленники могут попытаться определить настройки вашей зоны, отправив запросы на передачу зоны через вторичные DNS-серверы. Если вы заблокируете все запросы на передачу зоны через вторичные серверы, то злоумышленник не сможет получить информацию о зоне. Эта конфигурация не позволяет третьим лицам получить представление о том, как организована ваша внутренняя сеть. Заключение Всегда есть возможности для улучшения системной архитектуры DNS и ее безопасности. Постоянные угрозы скрываются и ждут, когда появится уязвимость в вашей информационной системе, чтобы воспользоваться ей. Но тем не менее, если вы будете следовать рекомендациям, описанным в данном руководстве, то вы охватите наиболее важные аспекты, которые необходимы для обеспечения безопасности и отказоустойчивости вашей инфраструктуры DNS.
img
Привет, дорогой любитель автоматизации с помощью бизнес - процессов! Мы очень рады, что в поисках полезной автоматизации обработки лидов в Битрикс24 ты нашел эту статью. Все потому, что мы тоже любим упрощать работу себе и своим сотрудникам, поэтому вот тебе кейс: Валерий – успешный менеджер по продажам. К нему прилетает лид. У Валерия есть только его электронная почта – оставлять телефон лид не захотел/не смог. После первичной обработки (выяснение потребностей, требований к услугам и так далее) лид сообщает, что не может ответить на некоторые вопросы и просит тайм – аут – предположим, пару дней. Конвертировать в сделку лида рано – мы не знаем ключевых параметров для формирования коммерческого предложения. Лид так и остается MQL (Marketing Qualified Lead) сущностью. В силу некоторых анатомических особенностей, Валерий бывает забывчив. В потоке новых лидов, которых он успешно конвертируется в SQL (Sales Qualified Lead), Валерий забывает про MQL лида. Но не забывает бизнес – процесс, о котором мы сейчас и расскажем. Битрикс24 бесплатно! Битрикс24 общается с лидом за вас Бизнес процесс работает следующим образом: Менеджер ставит лид в статус «Дожимаем лида»; Запускается цикл, который будет выполнятся до тех пор, пока лид находится в статусе «Дожимаем лида»; Бизнес-процесс берет паузу в 3 рабочих дня и спустя это время отправляет первое письмо лиду. Письмо будет отправляться от email адреса ответственного, с обращением к лиду по имени и формированием небольшой подписи в письме. Письмо отправляется такого содержания : Принято ли решение по проекту «%название_лида%». Параллельно с этим ответственному приходит сообщение об отправке внутри Битрикс24; После выполнения предыдущего шага, снова берется пауза в три рабочих дня, после чего отправляется письмо лиду другого содержания: Очень хотим с Вами работать :) Принято ли решение по проекту «%название_лида%»?. Параллельное уведомление приходит и ответственному; После чего, указанные выше шаги повторяются еще 2 раза (то есть общее число отправленных писем с интервалом в 3 рабочих дня будет равно 6); После отправки шестого письма бизнес процесс прервется; Очень советуем настроить триггеры в Битрикс24. Например, при событии «Входящее письмо» и «Входящий email» у вас будет переключаться статус – тем самым, при наличии активности по лиду (переписка, звонок) бизнес процесс будет прерываться. Блок-схема работы указана ниже: Настройка бизнес - процесса Итак, переходим к разбору полетов. Открываем CRM → Настройки → Автоматизация → Бизнес - процессы. В разделе «Лид» нажимаем добавить шаблон: даем первичное название и описание шаблону, предварительно сняв галочки на параметру автоматического запуска (запускать бизнес процесс мы будем изнутри другого процесса). Скачать бизнес – процесс для лидов в Битрикс24 Переходим во вкладку «Переменные» и создаем две служебных переменные, нажав «Создать переменную»: Идентификатор mail_choose Название: - выбор письма для отправки; Описание: - переменная содержит в себе либо 1, либо 2. В зависимости от значения, Заказчику будут отправляться разные письма; Тип: - целое число; Значение по умолчанию: - 0; Идентификатор count Название: - счетчик отправок; Описание: - когда клиенту будут отправлены 2 формата письма - мы будем увеличивать значение этой переменной на 1; Тип: - целое число; Значение по умолчанию: - 0; Общая структура нашего бизнес – процесса следующая: Первый элемент – «Цикл». Условно говоря, это блок, в котором задается некое условие, и, до тех пор, пока это условие выполняется, все элементы внутри цикла будут прогоняться снова и снова. Лишь в том случае, когда условие не выполнится, цикл будет завершен. В нашем случае условием «Цикла» будет статус лида. Пока он равен статусу «Дожимаем лида» - цикл жив: Итак, цикл начинается. Первым действием мы увеличиваем переменную mail_choose на 1 (ее значение по умолчанию 0). Это нужно для выбора письма, которое мы будем отправлять лиду. Для этого, мы выбираем блок «Изменение переменных», выбираем переменную «Выбор письма для отправки» и приравниваем ее к значению =({=Variable:mail_choose}+1). Переменная будет увеличена на 1. Добавляем блок «Пауза в выполнении». Здесь мы будем ставить бизнес – процесс на паузу на 3 рабочих дня. В разделе «Режим» выбираем чек-бокс «Время» и в поле «Дата» добавляем следующий код: =addworkdays({=System:Now}, 3) Приступаем к отправке. Данный блок будет отработан только после паузы в 3 рабочих дня. Первым делом, нам надо убедиться, что количество отправленных писем клиенту не равно 6 (мы не хотим отправлять клиенту больше 6 писем с напоминанием о себе). Счетчик с идентификатором count увеличивается каждый раз, когда клиенту отправляется четное письмо. Это значит, что уходит первое письмо – счетчик не увеличивается. Уходит второе – прибавляем 1 к переменной count. Уходит третье – ничего. Уходит четвертое - + 1. И так далее. В результате, когда переменная будет равна 3, мы будем завершать наш бизнес процесс. Если наш счетчик меньше 3, то мы переходим к выбору письма. Тут в игру вступает переменная mail_choose. Сейчас она равна 1 (мы увеличили ее в начале цикла). Поэтому, мы отправляем первое письмо и уведомление ответственному: После отправки уведомления бизнес процесс переходит в начало цикла. Там мы опять увеличиваем переменную mail_choose на 1, проходим паузу и условие. Теперь наша переменная равна 2, поэтому, мы отправляем лиду второй вариант письма: Второе письмо отправлено, и теперь, нам нужно обработать наши переменные: =({=Variable:count}+1) - увеличиваем счетчик отправок на 1; Выбор письма для отправки - приравниваем к 0; Вот и все. Теперь все происходит по новой, но переменная count = 1. Пока count не достигнет значения 3, цикл будет повторяться. Для этого, заранее настраиваем запуск этого бизнес – процесса при переключении статус лида на «Дожимаем лида». Давайте протестируем: переводим лида в нужный статус: О том, как создать запуск бизнес – процесса по переключению статус лида можете прочитать в этой статье. Через 3 дня нам (лиду) приходит первое письмо: И еще через 3 дня приходит второе письмо: Удачных полетов :)
img
Helm — это инструмент развертывания Kubernetes для автоматизации создания, упаковки, настройки и развертывания приложений и служб в кластерах Kubernetes. Kubernetes — это мощная система управления контейнеризацией для развертывания приложений. Для этого существует несколько независимых ресурсов, и для каждого требуется отдельный YAML-файл манифеста. В этой статье расскажем, что такое Helm и Helm Charts, а также как автоматизировать развертывание приложений в Kubernetes. Что такое Helm? Если бы Kubernetes был операционной системой, то Helm был бы менеджером пакетов. Ubuntu использует apt, CentOS использует yum, а Kubernetes использует helm. Helm развертывает пакетные приложения в Kubernetes и структурирует их в чарты (Helm Charts). Чарты содержат все предустановленные ресурсы приложения вместе со всеми версиями, которые помещены в один легко управляемый пакет. Helm упрощает установку, обновление, вызов зависимостей и настройку развертываний в Kubernetes с помощью простых CLI-команд. Пакеты программного обеспечения находятся в репозиториях или создаются. Почему нам нужен Helm? Объектами Kubernetes сложно управлять. Благодаря полезным инструментам освоение Kubernetes становится плавным и удобным. Helm автоматизирует обслуживание YAML-файлов для объектов Kubernetes, упаковывая информацию в чарты и анонсируя их в кластере Kubernetes. Helm отслеживает историю версий для каждой установки и изменения чарта. Откат к предыдущей версии или обновление до более новой выполняется понятными командами. Доступные команды: Completion — создает сценарий автозаполнения для указанной оболочки. Create — создает новый чарт с заданным именем. Dependency — управление зависимостями чарта. Env — информация о клиентской среде Helm. Get — загрузка расширенной информации об именованном релизе. Help — помощь по любой команде. History — получить историю релизов. Install — установить чарт. Lint — проверить чарт на возможные проблемы. List — список релизов. Package — упаковать каталог чарта в архив чарта. Plugin — установить, внести в список или удалить плагины Helm. Pull — загрузить чарт из репозитория или (опционально) распаковать его в локальный каталог. Repo — установка, внесение в список, удаление, обновление и индексация репозиториев чартов. Rollback — откат релиза к предыдущей версии. Search — поиск в чарте по ключевым словам. Show — показать информацию о чарте. Status — отображение статуса названного релиза. Template — локальное отображение шаблонов. Test — запустить тесты релиза. Uninstall — деинсталлировать релиз. Upgrade — обновить релиз. Verify — проверить, что чарт по указанному пути подписан и действителен. Version — распечатать информацию о версии клиента. Что вы можете сделать с помощью Helm? Helm позволяет разработчикам программного обеспечения развертывать и тестировать среду самым простым способом. Требуется меньше времени, чтобы перейти от разработки к тестированию и продакшену. Помимо повышения производительности, Helm предоставляет разработчикам удобный способ упаковки и отправки приложений конечным пользователям для установки. Как работает Helm? Helm и Kubernetes работают как клиент-серверное приложение. Клиент Helm отправляет ресурсы в кластер Kubernetes. Серверная часть зависит от версии: Helm 2 использует Tiller, тогда как Helm 3 избавился от Tiller и полностью полагается на Kubernetes API. Что такое Helm Charts? Чарты Helm (Helm Charts) — это пакеты Helm, состоящие из файлов и шаблонов YAML, которые преобразуются в файлы манифеста Kubernetes. Чарты могут повторно использоваться кем угодно и в любой среде, что уменьшает сложность и количество дубликатов. Папки имеют следующую структуру: Как работают чарты Helm? Три основные концепции чартов Helm: Чарт — предварительно настроенный шаблон ресурсов Kubernetes. Релиз — чарт, развернутый с помощью Helm в кластере Kubernetes. Репозиторий — общедоступные чарты. Рабочий процесс заключается в поиске чартов через репозитории и создании релизов путем установки чартов в кластеры Kubernetes. Структура чарта Helm Файлы и каталоги чарта Helm имеют определенную функцию: Название Тип Функция charts/ Каталог Каталог для управляемых вручную зависимостей чарта. templates/ Каталог Написанные на языке Go файлы шаблонов, объединенные с конфигурационными значениями из файла values.yaml и предназначенные для генерации манифестов Kubernetes. Chart.yaml Файл Метаданные о чартах, такие как: версия, имя, ключевые слова для поиска и так далее. LICENSE (опционально) Файл Лицензия на чарт в текстовом формате. README.md (опционально) Файл Удобочитаемая информация для пользователей чарта. requirements.yaml (опционально) Файл Список зависимостей чарта. values.yaml Файл Настройки чарта по умолчанию. Создавайте чарты Helm вручную или собирайте общедоступные чарты из репозиториев. Репозитории чартов Helm Репозитории содержат чарты, которые могут быть установлены или предоставлены для доступа другим пользователям. Helm обеспечивает поиск напрямую из клиента. Существует два основных типа поиска: helm search hub — поиск через Artifact Hub из множества репозиториев. helm search repo — поиск через репозитории, добавленные в локальном клиенте Helm с помощью helm repo add. Без каких-либо фильтров в результатах поиска отображаются все доступные чарты. Чтобы уточнить запрос, добавьте условие поиска. Например: helm search hub wordpress Когда найдете подходящий чарт, установите его с помощью helm install. Релизы чартов При установке чарта создается новый пакет. Команда helm install принимает два аргумента: helm install <release name> <chart name> Запуск helm install выводит полезную информацию и указывает, следует ли вам предпринять какие-либо действия для установки. Чарты кастомизируемы и легко настраиваются перед установкой. Релизы Helm легко поддерживать и откатывать в случае любых нежелательных изменений.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59