Милі та пухнасті

Category: Uncategorized

  • Что такое брандмауэр веб-приложений (WAF)?

    Что такое брандмауэр веб-приложений (WAF)?

    Брандмауэр WAF или веб-приложений помогает защитить веб-приложения, фильтруя и отслеживая HTTP- трафик между веб-приложением и Интернетом. Это , как правило , защищает веб – приложение от атак , таких как межсайтовая подделка , кросс-сайт-сценарии (XSS) , включение файлов и инъекция SQL и др. WAF является защитой протокола уровня 7 (в модели OSI ) и не предназначена для защиты от всех типов атак. Этот метод ослабления атаки обычно является частью набора инструментов, которые вместе создают целостную защиту от целого ряда векторов атак.

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

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

    DDOS. Как работает WAF

    В чем разница между WAF черных и белых списков?

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

    Что такое сетевые, хостовые и облачные WAF?

    WAF может быть реализован одним из трех различных способов, каждый из которых имеет свои преимущества и недостатки:

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

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

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

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

  • Резервное копирование и восстановление корпоративных данных

    Резервное копирование и восстановление корпоративных данных

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

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

    С другой стороны, очень легко подготовить к работе Quest NetVault Backup. При этом упрощается резервное копирование на предприятии, от установки и развертывания до повседневного управления и эксплуатации, и достигается надежная защита всей ИТ-структуры, а в конечном итоге — экономия времени, денег и других ресурсов.

    Если вы управляете растущей и разнообразной ИТ-средой, NetVault Backup защитит все ваши данные. Продукт поддерживает большинство операционных систем и виртуальных сред, предусматривает современные средства защиты подключенных к сети устройств памяти и баз данных (в том числе Oracle, Exchange, SQL Server, DB2 и SAP) и позволяет выполнять резервное копирование на диск или ленту. Одним словом NetVault Backup надежно прикрывает ваш тыл

    Простота установки и развертывания

    Существует три варианта установки NetVault Backup: графический, текстовый и автоматический. И все три проектировались таким образом, чтобы упростить процесс и приспособить его к нуждам пользователя.

    В графическом режиме установки вы просто проходите последовательно по нескольким экранам настройки, и NetVault Backup готов к работе через несколько минут. NetVault Backup можно установить и в текстовом режиме для работы с системами UNIX или Linux.

    Автоматический режим представляет собой метод принудительной установки, с помощью которого можно установить один или несколько компонентов NetVault на удаленных компьютерах Windows без помощи (или с небольшим участием) пользователя.

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

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

    Простота использования

    Что если в инфраструктуре компании сочетаются локальные, «облачные» и гибридные технологии? А в сети присутствуют как физические, так и виртуальные компоненты? Можно упростить защиту данных в сложной среде с помощью единственного решения. Пользовательский интерфейс NetVault Backup легко освоить, и в нем предоставляется только нужный набор функций.

    Защита всей ИТ-структуры

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

    Можно обеспечить безопасность устаревших систем без необходимости заменять или добавлять что-то для поддержания средств резервного копирования и восстановления данных на предприятии в оптимальном состоянии. NetVault Backup одновременно поддерживает растущую и развивающуюся инфраструктуру. Новые технологии и системы будут защищены единым решением.

    Резервное копирование можно выполнять в виртуальные библиотеки лент (VTL), на ленточные накопители, оптические накопители, устройства дедупликации или же можно выбрать «облачное» хранилище данных через шлюз веб-служб Amazon. Кроме того, вы получаете расширенную защиту приложений и баз данных для Oracle, Exchange, SharePoint, SQL Server, MySQL, PostgreSQL, DB2 и SAP.

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

    Благодаря интуитивно понятному интерфейсу на основе браузера NetVault Backup позволяет управлять резервным копированием и восстановлением данных на предприятии с использованием настольного компьютера, ноутбука или планшета из любого места и в любое время.

    Если в вашей компании применяется процедура единого входа, то NetVault Backup интегрируется с Active Directory (AD), что позволяет задействовать для входа существующие учетные данные AD. Таким образом оптимизируются безопасность и управление доступом в среде резервного копирования. Кроме того, вы можете заметно усовершенствовать управление правами, импортируя пользовательские группы из AD непосредственно в NetVault Backup.

    Привилегии, права, доступ на основе ролей и параметры использования — все они одинаково успешно применяются в NetVault Backup. Кроме того, более быстрый и простой вход обеспечивает повышенную производительность вашей команды.

    Повседневное управление потоком данных

    В процессе повседневной работы с NetVault Backup вы будете удивлены, насколько просто управлять потоками данных. Панель мониторинга обеспечивает единое графическое представление всех объектов в среде, то есть вы можете постоянно отслеживать свои резервные копии в реальном времени. В результате не составляет труда находить и быстро устранять узкие места в различных элементах инфраструктуры.

    Вы отметите заметные улучшения в производительности и эффективности хранения данных благодаря функциям дедупликации и сжатия на стороне клиента через интеграцию с программно-определяемой дополнительной платформой хранения Quest QoreStor, которую можно развернуть на типовом оборудовании. Создавайте, используйте целевые объекты и управляйте ими из интерфейса NetVault Backup.

    Данное решение также интегрируется с другими технологиями дедупликации, в том числе с линейкой продуктов Dell EMC Data Domain и технологией Data Domain Boost. NetVault Backup по-настоящему показывает себя, когда кто-то теряет файл или происходит частичный сбой системы. Мощные средства поиска позволяют просматривать миллионы файлов или объектов и получать результат в течение нескольких секунд.

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

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

    Все системы в любое время

    Это все хорошо, но как быть с пользователями и деловой активностью, которая не должна прерываться даже в случае аварии? NetVault Backup позволяет обеспечить доступность приложений в любых обстоятельствах. Сократите воздействие на хост-систему, используя сверхбыстрые моментальные снимки на основе массивов, и сведите к минимуму потери данных.

    NetVault Backup поддерживает ориентированные на приложения моментальные снимки SAN, обеспечивающие значительно более быстрое и простое резервное копирование, нежели традиционные системы архивации. При этом удается получить показатели RTO (цель времени восстановления) и RPO (целевая точка восстановления), практически недостижимые в традиционных системах архивации.

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

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

    NetVault Backup распределяет виртуальные резервные копии среди многих клиентов из единого представления. В результате упрощается не только интерфейсный, но и внутренний компонент инфраструктуры.

    Другое преимущество для корпоративной стратегии резервного копирования и восстановления — повышение пропускной способности и производительности, достигаемое благодаря NetVault Backup.

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

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

    Простота экономии ресурсов

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

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

    Например, если нужно обновить определенный подключаемый модуль для VMware, можно сосредоточиться исключительно на нем, не тратя времени и ресурсов на обновление базовой технологии в NetVault Backup или на сервере резервного копирования.

    Редакции NetVault Backup Standard Capacity Edition и NetVault Backup Enterprise Capacity Edition обеспечивают высокую гибкость, позволяя развертывать нужное сочетание операционной системы, базы данных и подключаемых модулей приложения.

    Если вам требуется решение для VMware, Windows, Linux и UNIX, то NetVault Backup будет прекрасным выбором, без необходимости в специальных ключах лицензирования для каждого типа сервера. Если компания развивается, то вам не составит труда масштабировать лицензии на основе мощностей в соответствии с новыми приоритетами.

    (источник : Журнал “Windows IT Pro/RE”)

  • Обеспечиваем соответствие требованиям регламента по защите данных

    Обеспечиваем соответствие требованиям регламента по защите данных

    Главная из проблем, которые одинаково заботят администраторов баз данных, директоров по защите данных и управляющих ИТ,— безопасность данных клиентов в контексте общего регламента по защите персональных данных (GDPR), а также способность реляционной базы данных, или базы NoSQL, обеспечить соответствие новым требованиям.

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

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

    Кроме того, вызывает немало вопросов способность систем управления базами данных обеспечить соответствие требованиям GDPR. Особую проблему могут представлять базы данных типа NoSQL.

    Что же представляют собой базы данных, отличные от SQL, и что отличает их от таких реляционных баз данных, как Microsoft SQL Server или Oracle? Чтобы ответить на эти вопросы, нужно вернуться в 60-е годы XX века.

    Краткая история баз данных, отличных от SQL

    Базы данных NoSQL первоначально назывались non SQL или «нереляционные», но сегодня обозначаются термином not only SQL («не только SQL»). В современных NoSQL способы хранения и извлечения данных иные, нежели в таблицах и соединениях между таблицами традиционных реляционных моделей.

    Базы данных NoSQL существуют уже более 50 лет, но они не получали широкого распространения до появления сетевых технологий, известных как Web 2.0, в 1990-х, а также социальных сетей и розничных гигантов, таких как Facebook, Google и Amazon.

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

    Первоначально разработчики баз данных NoSQL старались обойти реляционные ограничения, однако впоследствии избрали более центристский подход к управлению данными, близкий к реляционному: они пожертвовали некоторыми свойствами транзакций, такими как неделимость, целостность, изолированность и устойчивость (от англоязычных терминов Atomicity, Consistency, Isolation, Durubility), обозначаемыми как ACID, ради доступности и быстродействия.

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

    Базы данных типа «ключ-значение»

    Базы данных типа «ключ-значение» (Key-Value) используют дополнительный, ассоциативный, массив (то есть «карту» или «словарь») для обозначения отношений различных ключей вместо типовых таблиц и объединений в реляционной базе данных.

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

    Примером может служить предприятие по прокату фильмов: только один человек может арендовать фильм в определенный момент времени, и пара “ключ-значение” может выглядеть так: “Первому игроку приготовиться” и “Тревор Форд”.

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

    При этом возникает серьезная проблема с парами «ключ-значение», использующими естественные ключи, подобно тому, как это бывает в реляционной базе данных с естественными ключами: они персонально идентифицируемы. В приведенном выше примере легко идентифицировать человека по имени — Тревор Форд. Если Тревор Форд попросит забыть свои данные, то удовлетворить требованиям GDPR будет трудно.

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

    Приведу несколько примеров баз данных NoSQL типа «ключ-значение»:

    • Apache Ignite;
    • Couchbase;
    • Riak;
    • Redis;
    • MUMPS;
    • база данных Oracle NoSQL;

    Документоориентированные базы данных

    Базовый элемент хранилища документов — документ. Хотя во всех продуктах данной категории применяются различные подходы, неизменно предполагается, что данные в документах хранятся в некотором стандартном формате, таком как JSON или ХМБ. Каждый документ имеет уникальный ключ, идентифицирующий конкретный документ, и в каждом документе хранятся значения, связанные с записью (в реляционных терминах).

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

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

    С хранилищами документов возникают те же проблемы, что и с базами данных типа «ключ-значение», когда речь идет о предусмотренном GDPR праве быть забытым и даже требовании безопасного экспорта данных пользователя. Выуживание персонально идентифицированных данных из огромного множества документов может оказаться делом нелегким. Некоторые примеры баз данных документов:

    • CouchDB;
    • CosmosDB;
    • MongoDB;
    • IBM Domino.

    Базы данных, построенные на графах

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

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

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

    • Apache Giraph;
    • MarkLogic;
    • OrientDB;
    • ArangoDB.

    Работа с реляционными данными

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

    Вложения и ненормализованные данные

    Часто используемый метод: сохранение большего объема данных, причем ненормализованных. Сохранив как суррогатный ключ (например, идентификатор пользователя), так и имя, фамилию и т.д., можно будет создать одно обращение к данным. За быстродействие приходится расплачиваться повышенными требованиями к ресурсам памяти. Метод может привести к размножению персонально идентифицируемых данных, а это увеличивает вероятность нарушений GDPR и затрудняет достижение соответствия правовым нормам.

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

    (источник : Журнал “Windows IT Pro/RE”)

  • Социальная инженерия в тесте на проникновение

    Социальная инженерия в тесте на проникновение

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

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

    Историй проверки проникновения с использованием социальной инженерии множество, вот например одна из них:

    Сотрудник, компании которой заказали тестирование на физическую и информационную безопасность банка сделал следующее, одев куртку с эмблемой  конференции по безопасности, зашел в отделение банка, дождался подходящего момента, когда руководитель вышел из помещения, а сотрудники были заняты клиентами, это не сложно учитывая прозрачные перегородки. Зашел в помещение только для сотрудников с флешкой на которой был троян, вставил её в первый попавшийся компьютер, на немой вопрос сотрудников, ответил «Все в порядке, меня прислали проверить USB подключения». Посидев какое-то время и покатавшись на стуле, в это время троян выполнил свою работу, сотрудник наемной компании, понял что это была сильно простая задача, он встал, громко сказав, компьютер сломан я забираю его в ремонт, забрав системник беспрепятственно вышел мимо охраны.

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

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

    Социальные сети – идеальный инструмент для социальной инженерии.

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

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

    Готовимся к тесту на проникновение

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

    Gophish – ПО которое поможет быстро определить реакцию работников на различные письма. В самом начале данный фреймворк использовался для экпрес ИТ аудита безопасности в части соц инженерии. Но со выменем оброс полезным функционалом.

    Как происходит тестирование

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

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

    На основе тестовой рассылки можно определить эфективные методы проникновения.использование gophish для тестирования проникновения

    GoPhish. Возможности.

    • Рассылка писем по заранее созданным шаблонам
    • Параллельное проведение атак
    • Информативный “Dashboard”

    автоматизация фишинга gophish

    gophish по для тестирования безопасности

    GoPhish. Контроль процесса.

    Детализированная информация по каждому почтовому адресу 

    • Открытие письма
    • Клик ссылки
    • Просмотр отправленных данных

    автоматизация проверок взлома

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

  • Как проверить сайт на безопасность

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

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

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

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

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

    Если бы на источнике, подвергшемся атаке, проводился аудит безопасности сайта, то всего этого можно было бы избежать. Можно начать с элементарного: запустите подбор паролей для администраторской учетной записи. При выявлении уязвимостей, добрая часть угроз устранилась бы сама собой. Также важно распределять доступ к критически важным данным.

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

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

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

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

    Хаотичная атака ради случайной добычи

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

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

    Направленная атака

    Эти типы атак наиболее опасны и распространены среди крупных компаний, у которых есть чем порадовать хакеров. Зачастую, они направлены на конкретную цель: уничтожение данных, кража ценной информации с серверов или полный саботаж инфраструктуры.

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

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

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

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

  • Защита персональных мед данных

    Персональные медицинские данные пациента (protected health information PHI), предметом защиты HIPAA. К такой информации относится:

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

    Требования правил безопасности

    Общие положения и требования правил безопасности распространяются на 5 основных областей.

    • Физические меры безопасности
    • Административные меры безопасности
    • Организационные мероприятия
    • Технические меры безопасности
    • Политики, процедуры и требования к документации

    Задачей правил безопасности, заключается в обеспечении гарантии конфиденциальности информации, а также доступности и целостности информации о состоянии здоровья пациента (Protected Health Information, PHI). Благодаря этому формируется правильный подход управления рисками различных организаций.

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

    Организациям в здравоохранении требуются не малые ресурсы для реализации правил и работоспособности своих систем. Отдел безопасности должен сотрудничать с консультантами по HIPAA и юристом организации.

    Административные меры безопасности

    HIPAA определяет соблюдение следующих правил для любой организации

    1. Управление безопасностью. Сюда входит регулярный анализ рисков; соответствующие меры безопасности для управления рисками; политика санкций, направленная на принудительное соблюдений требований; регулярный просмотр записей в журналах, содержащих информацию о выполняемых действиях.
    2. Назначение лиц, ответственных за безопасность. Должен быть назначен человек, отвечающий за вопросы безопасности.
    3. Меры безопасности, связанные с человеческим фактором. Следующие компоненты рассматриваются применительно к конкретной организации: процедуры авторизации, установление уровня допуска, процедуры увольнения.
    4. Управление доступом к информации. Обязательным компонентом является изоляция работы информационных центров здравоохранения. А эти компоненты рассматриваются применительно к конкретной организации: процедуры авторизации доступа, установления факта доступа и процедуры модификации.
    5. Понимание необходимости мер безопасности и обучение. Эти компоненты рассматриваются применительно к конкретной организации: периодическое обновление положений безопасности; защита от вредоносного программного обеспечения; мониторинг входа в систему и управление паролями.
    6. Процедуры, связанные с возникновением инцидентов безопасности. Политики и процедуры, относящиеся к инцидентам безопасности, являются обязательными.
    7. План на случай возникновения непредвиденных обстоятельств. Эти компоненты являются обязательными: план создания резервных копий информации, план восстановления после стихийных бедствий и план действий в чрезвычайных обстоятельствах. Следующие компоненты рассматриваются применительно к конкретной организации: периодическая проверка и пересмотр планов, оценка относительной важности определенных приложений.
    8. Оценка. Необходимо проводить периодическую оценку защиты на местах в ответ на изменения в окружении.
    9. Контракты, связанные с ведением бизнеса, и другие мероприятия. Необходимо наличие контрактов, определяющих соответствующие меры безопасности, с любой организацией, совместно использующей PHI.

    Физические меры безопасности

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

    1. Управление доступом в помещение. Следующие компоненты рассматриваются применительно к конкретной организации: планы, разработанные на случай возникновения непредвиденных обстоятельств; план безопасности помещений; контроль доступа и подтверждения подлинности, процедуры для регистрации ремонтных работ и модификаций физических средств защиты.
    2. Используемые рабочие станции. Политика для определения физических параметров рабочих станций, с которых можно обращаться к PHI.
    3. Безопасность рабочих станций. Физические меры безопасности для всех рабочих станций, с которых можно обращаться к PHI.
    4. Контроль устройств и носителей информации. Эти компоненты являются обязательными: процедуры для размещения PHI и носителей, на которых она хранится, удаление PHI перед повторным использованием носителей. А эти компоненты рассматриваются применительно к конкретной организации: записи о перемещении аппаратных средств и носителей, создание резервных копий PHI перед этим перемещением.

    Технические меры безопасности

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

    1. Управление доступом. Эти компоненты являются обязательными: назначение каждому пользователю уникального идентификатора, реализация процедур доступа в чрезвычайных обстоятельствах. Следующие компоненты рассматриваются применительно к конкретной организации: автоматический выход из системы и шифрование/дешифрование PHI.
    2. Управление аудитом. Включает реализацию механизмов для записи и исследования любой деятельности в системе, которая содержит PHI.
    3. Целостность. Разработка механизмов аутентификации электронной PHI.
    4. Аутентификация личности или объекта. Разработка механизмов подтверждения подлинности личности тех, кто пытается получить доступ к PHI.
    5. Безопасность при передаче данных. Способы выявление неправомочных модификаций PHI в процессе передачи и способы шифрования PHI.

    Организационные меры безопасности

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

    Политики, процедуры, и требования к документации

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

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

  • Контейнеры и вычислительная модель без сервера

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

    Однако решить эту задачу необходимо, если вы хотите воспользоваться контейнерами или вычислительной моделью без сервера в «облаке». В этой статье мы рассмотрим различные современные «облачные» контейнеры и платформы без сервера.

    Контейнеры и функции без сервера

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

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

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

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

    Контейнер AWS и варианты вычислений без сервера

    Обзор «облачных» контейнеров и служб вычислений без сервера мы начнем с предоставляемых на Amazon Web Services, или AWS. Самый простой (и вместе с тем трудоемкий) способ запуска контейнеров на AWS — подготовить экземпляры виртуальных машин с использованием ЕС2, установить на них Docker и разместить контейнеры.

    Однако для этого требуется выполнить много работы вручную, и решение сложно масштабировать. Поэтому AWS предоставляет службу Elastic Container Service, или ECS. ECS автоматизирует большинство задач подготовки инфраструктуры и развертывания контейнеров, необходимых для использования контейнеров Docker. ЕС2 по-прежнему остается базовой инфраструктурой, но это обстоятельство не имеет особого значения для ИТ-специалистов.

    В ECS используется собственный инструмент оркестровки для управления кластерами контейнеров. Если вы предпочитаете Kubernetes, открытую платформу оркестровки, то можно задействовать EKS. EKS похожа на ECS, но в ней решением оркестровки является Kubernetes.

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

    Поэтому в 2017 году AWS представила Fargate, специальный «вычислительный механизм» для инфраструктуры контейнеров на AWS. Fargate не является отдельной службой контейнеров. Его можно рассматривать как особый режим развертывания для ECS и EKS, в котором автоматизировано управление оркестровщиком, наряду с большинством других компонентов контейнеризованной среды.

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

    В отношении вычислений без сервера AWS отличается меньшей сложностью. Предоставляется только одно решение без сервера, именуемое Lambda. Хотя Lambda не был первым продуктом для вычислений без сервера на рынке (технологии, которые в той или иной степени обходились без сервера, разрабатывались примерно за десять лет до выпуска Lambda в 2014 году), это было первое широко рекламируемое решение без сервера, и оно сыграло важную роль в повсеместном распространении вычислений без сервера.

    Контейнеры и вычисления без сервера на Azure

    Сложность служб контейнеров в «облаке» Microsoft Azure довольно высока. В прошлом Azure предоставляла службу контейнеров Azure Container Service. После того как была добавлена полная поддержка оркестровщика Kubernetes, название изменили на Azure Kubernetes Engine.

    Ситуация становится более запутанной, если учесть, что Kubernetes — не единственный оркестровшик, который можно использовать на Azure, он также поддерживает оркестровщики контейнеров DC/OS и Docker Swarm. Это означает, что, размещая контейнеры на Azure, можно задействовать почти любой оркестровшик, хотя представители Microsoft сегодня говорят только о Kubernetes.

    В решении без сервера Azure разобраться проще. Оно называется Azure Functions и делает, в сущности, то же самое, что AWS Lambda, хотя между этими двумя службами есть небольшие различия в поддерживаемых языках программирования, времени выполнения функций и других деталях, выходящих за рамки этой статьи.

    Контейнер и решение без сервера Google Cloud

    Третье и последнее широко распространенное общедоступное «облако» для контейнеров и вычислений без сервера — Google Cloud. В отличие от AWS и Azure, Google с первых шагов сделала ставку на Kubernetes, и «облачная» служба контейнеров компании всегда называлась Google Kubernetes Engine, или GKE. Чтобы использовать иной оркестровшик контейнеров в Google Cloud, вам придется подготовить собственные виртуальные машины и управлять кластером контейнеров вручную.

    Google Cloud Functions — служба вычислений без сервера от Google. Cloud Functions безупречно работает как решение без сервера, но основное внимание Google обращено на контекст Firebase, мобильную инфраструктуру разработки, интегрированную с Cloud Functions. Словом, если вы хотите разрабатывать мобильные приложения и использовать в них функции без сервера, то Firebase и Google Cloud Functions — превосходный выбор. Но если вам нужны исключительно вычисления без сервера, то предпочтительны Lambda или Azure Functions, которые не проектировались в первую очередь в расчете на мобильную среду.

    (источник: Журнал “Windows IT PRO”)

    Вы можете развернуть контейнер используя наше облачное решение. Чтобы получить консультацию и помощь по этому вопросу обращайтесь +38 (067) 523-77-57

  • Функции аварийного восстановления в Windows Server 2019

    Борьба с катастрофой – это, без сомнения, последнее, чем хочет заниматься каждый бизнес. Однако, если это время наступит, вы захотите убедиться, что вы используете правильные технологии, чтобы обеспечить максимально быстрое восстановление с наименьшей потерей данных. Windows Server является ядром ИТ-инфраструктуры большинства предприятий, и в октябре 2018 года Microsoft выпустила новую версию Windows Server 2019, которая определенно расширяет возможности её доступности и возможности аварийного восстановления. Давайте подробнее рассмотрим различные функции аварийного восстановления (DR), включенные в Windows Server 2019.

    Отказоустойчивая кластеризация Windows

    Отказоустойчивая кластеризация Windows (WFC) по-прежнему является основной технологией обеспечения высокой доступности и аварийного восстановления Microsoft для Windows Server 2019. WFC обеспечивает защиту на уровне сервера как для плановых, так и для незапланированных простоев. WFC могут иметь до 64 узлов в Windows Server 2012, 2012 R2 и 2016, и их можно использовать локально для обеспечения высокой доступности (HA), и географически распределенные кластеры также могут обеспечить DR. Вы устанавливаете WFC как компонент Windows с помощью диспетчера сервера или PowerShell.

    В Windows Server 2019 Microsoft решила проблему перемещения кластеров из одного домена в другой с помощью миграции междоменных кластеров. В предыдущих версиях WFC перемещение WFC в новый домен требовало удаление и повторного создания членства в WFC. Windows Server 2019 предоставляет два командлета PowerShell: Remove-ClusterNameAccount и New-ClusterNameAccount, которые удаляют учетную запись имени кластера из исходного домена Active Directory, закрывают кластер и удаляют его из исходного домена. Затем добавляют узлы кластера в рабочую группу, присоединяют их к новому домену и создают новые ресурсы кластера в новом домене. Кроме того, новая функция Server 2019 Cluster Sets поддерживает группирование нескольких кластеров с использованием Master кластерного ресурса, работающего на одном кластере, который работает с Cluster Set Worker в кластерах-членах, что позволяет выполнять гипермасштабирование кластеров, а также виртуальных машин Live Migrate между членами кластеров.

    Реплика Hyper-V

    Разработанная как технология для DR, Hyper-V Replica была впервые анонсирована с Windows Server 2012 и практически не изменилась в Windows Server 2019. Как следует из ее названия, Hyper-V Replica позволяет создавать и поддерживать обновленную копию или реплику выбранных Виртуальных машин на другом хосте Hyper-V. Когда вы включаете реплику Hyper-V для выбранной виртуальной машины, хост-сервер Hyper-V создаст идентичную копию этой виртуальной машины на целевом устройстве, затем начинает запись журнала изменений для основной виртуальной машины, а затем периодически пересылает и применяет изменения на целевой реплике Hyper-V. Реплика Hyper-V может иметь одну целевую первичной реплики и одну целевую расширенной реплики. В настоящее время Hyper-V Replica не поддерживается новым Центром администрирования Windows. Вам все еще нужно использовать диспетчер Hyper-V для настройки репликации.

    Репликация хранилища

    Microsoft представила Storage Replica Windows Server 2016. Реплика хранилища (SR) обеспечивает репликацию на уровне блоков с любого тома на одном сервере или кластере на другой том, что позволяет разносить WFC на географические расстояния без использования сторонних технологий репликации хранилищ. SR поддерживает как синхронную репликацию без потери данных для сценариев с высокой отказоустойчивостью, так и асинхронную репликацию с возможной потерей данных для географически разнесенных сценариев аварийного восстановления. Вы устанавливаете SR как компонент Windows с помощью диспетчера сервера или PowerShell. Ранее функция Windows Server 2019, предназначенная только для центра обработки данных, теперь предоставляет ограниченную поддержку SR в стандартной версии. Стандартный SR ограничен одним томом на сервер, одним партнерством на том и 2 ТБ томами. Windows Server 2019 SR поддерживает новую функцию тестирования отказоустойчивости, которая позволяет подключать целевой том хранения для проверки репликации, а также поддерживается новым Центром администрирования Windows.

    Windows Server Backup

    Резервное копирование является наиболее фундаментальной технологией аварийного восстановления, и всем организациям требуется резервное копирование серверов независимо от того, какие другие технологии аварийного восстановления они могут использовать. Резервное копирование Windows Server 2019 по существу такое же, как и в предыдущей версии. Если вы собираетесь использовать Windows Server Backup, сначала необходимо установить его как компонент Windows с помощью диспетчера сервера или PowerShell. Windows Server Backup обеспечивает возможность резервного копирования локальных данных и виртуальных машин Hyper-V, но большинство компаний предпочитают использовать сторонние инструменты резервного копирования, которые обеспечивают шифрование, дедупликацию, резервное копирование виртуальных машин на уровне образов и интеграцию в облачную среду. Новый Центр администрирования Windows позволяет запускать резервное копирование Azure для резервного копирования систем Windows Server в Azure.

    Kubernetes и Windows Server 2019

    Хотя это все еще в стадии разработки, одной из новейших технологий с открытым исходным кодом, поддерживаемой Window Server 2019, которая будет оказывать влияние на HA и DR, является Kubernetes. С Windows Server 2019 Microsoft проделала большую работу как на платформе Windows Server, так и на фронте с открытым исходным кодом, чтобы обеспечить взаимодействие между Windows и Kubernetes. Блог Microsoft Network назвал это изменение в Windows «пробуждением Kubistential». Kubernetes может заменить WFC для SQL Server 2019 HA, а Windows Server 2019, он сможет развертывать кластеры Kubernetes со смешанными ОС в локальном центре обработки данных или Azure.

  • Виртуализация контейнера 1C на Proxmox

    В этой статье мы рассмотрим процесс виртуализации контейнера 1С на Proxmox и те трудности, с которыми сталкивается пользователь в ходе его выполнения. Разделим все на несколько этапов.

    Этап 1: Создайте план и оцените риски

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

    Этап 2: Интеграция 1С

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

    Этап 3: Хост

    Виртуализация 1С осуществляется за счет Рroxmox, который включает в себя удобные инструменты в виде lxc.mount. Этот метод позволит смонтировать необходимые хосты в указанное место, то есть, в контейнер 1С. Распределяйте место и каталоги правильно, чтобы не засорять систему и иметь возможность провести логирование.

    Этап 4: Настройка сервера и приложений

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

    База данных

    Самым оптимальным решением для виртуализации 1С является БД PostgreSQL. Но вы можете внедрить любое другое решение. Чтобы все прошло быстро, можно клонировать шаблоны БД сервера в необходимом количестве. Естественно, каждая копия должна включать в себя все элементы для организации логирования.

    Бэкап легче настроить через pg_dump all, который будет размещаться в нужных каталогах. А вот для формирования файла лучше подходит $hostname.

    Сервер приложений

    Контейнер 1С отлично работает на 64-разрядных ОС. 32-разрядные могут замедлить работу и быть несовместимы с некоторыми надстройками. Однако, даже такие версии ОС допустимы. Виртуализация 1С пройдет быстрее, если вы установите Centos и дополнительно пакеты с официального сайта.

    Этап 5: Настройка лицензий

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

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

    Виртуализация 1С на Proxmox тем и хитра, что меняет ID первого ядра на нулевое значение. Вам покажется, что система некорректно отображает количество ядер. Тем более, после наращивания мощности, Proxmox все равно потребует установить новую лицензию для контейнера 1С.

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

    Специалисты с опытом более 10-и лет готовы проконсультировать вас по вопросам виртуализации 1С, а также оказать профессиональную помощь в ее реализации. Обращайтесь office@itfb.com.ua

  • Как развивался DevOps

    Мы часто публиковали материалы по управлению разработкой программ с помощью DevOps. Однако, далеко не каждый может объяснить, откуда произошла эта методика. Именно этот пробел мы и собираемся заполнить в данной статье.

    Что такое «Dev» и «Ops»

    Само понятие DevOps еще только начало зарождаться в голове у Патрика Дебуа, бельгийского ИТ-шника, в 2007 году, когда он поставил перед собой цель глубже проанализировать работу в ИТ-индустрии. Именно поэтому молодой специалист трудоустраивался в различные компании на короткий срок, причем, стараясь занимать самые разнообразные должности. Неизменным правилом было лишь одно – работать в ИТ-сфере.

    И вот однажды, Патрику нужно было провести тестирование целого хранилища данных, которое переносилось из одного места в другое. Там он и начал тесно сотрудничать с двумя группами специалистов: разработчиками из dev и непосредственно теми, кто занимался эксплуатацией в ops. Благодаря этому, Дебуа ощутил на себе всю соль работы в таких условиях и проблемах в управлении разработкой программного обеспечения в целом.

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

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

    Мероприятие DevOpsDays

    В 2009 году Патрик Дебуа вдохновился прямой трансляцией доклада Джона Оллспоу и Пола Хэммонда , которые совместно трудились в компании Flickr. Бельгиец решил создать нечто подобное, потому что видел уровень отклика подобных мероприятий. Так появилась идея собрать как можно больше разработчиков и системных администраторов в городе Гент и устроить конференцию под названием «DevOpsDays».

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

    Распространение DevOps и его участие в процессе разработки

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

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

    Первыми решились на эксперимент такие специалисты, как Майкл Коте и Джей Лайман. Они работали в компаниях Red Monk и The 451 Group соответственно. Первое сообщение о том, что они начали работать по методике DevOps опубликовано в начале весны 2011 года в яркой презентации.

    Уже в 2015 году всем стало понятно, что остановить массовое DevOps движение невозможно. Да и зачем, если оно приносит реальную пользу? Согласно статистике, уже на то время количество компаний, которое должно было перейти на управление разработкой программного обеспечения по новой методике, составляло более 20%.

    После таких громких заявлений, самые крупные участники ИТ-рынка решили тоже попробовать внедрить DevOps. А это уже весомый аргумент! Так DevOps превратился в мейнстрим.

    Зачем нужно знать историю DevOps

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

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

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

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