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

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

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

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

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

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

Комплектующие
Каждый сервер состоит из следующих комплектующих:

• корпус (идет сразу с блоком питания);
• материнская плата;
• оперативная память;
• процессоры;
• накопители;
• дисковые контроллеры (если есть в заказе);
• видеокарты (если есть в заказе).

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

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

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


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

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

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

Установка материнской платы
Непосредственно перед установкой материнской платы инженеры выполняют некоторые подготовительные действия:

• надевают тонкие перчатки;
• надевают заземляющий браслет.

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

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

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

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

Установка процессоров
Эта операция, пожалуй, самая тонкая и требующая внимательности. Еще 10 лет назад процессоры имели удобные «ножки», а сокеты представляли собой пластиковую матрицу с отверстиями. Благодаря этому достаточно было всего лишь аккуратно вставить процессор в сокет и закрыть защелку. Начиная с сокета LGA 775 процессоры лишились «ножек», остались только ровные контактные площадки. Сокеты, наоборот, теперь имеют контакты, однако они настолько маленькие и хрупкие, что любая операция с установкой процессора должна быть максимально точной.
Современный сокет FCLGA3647

Процессор линейки Intel Xeon Scalable


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

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

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

• нежелательно использовать нечетное количество планок (актуально для процессоров Intel® Xeon® линейки E5);
• следует поканально распределять память, чтобы система могла задействовать все возможные режимы механизмов управления;
• в одном сервере желательно использовать память с одинаковым значением задержки (latency), напряжения и частоты, в диапазоне, который поддерживает материнская плата.

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

Установка накопителей
Тут все просто. Дисковые накопители закрепляются в штатных салазках, после чего вставляются в сервер. Если были заказаны дисковые контроллеры или дополнительные сетевые карты, то они устанавливаются в соответствующие PCI-E слоты и закрепляются винтами. После того, как все установлено на свои места, инженер отдела сборки еще раз проверяет соответствие всех комплектующих заказу и отправляет сервер на стенд для прошивки и тестирования.

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

Забавный факт: один монтажный юнит по высоте в точности равен одному вершку (древнерусская единица длины).

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

Воздушный поток разделяется поровну между всеми GPU


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

Так выглядит сервер с аккуратно уложенными кабелями, которые не мешают прохождению воздушного потока


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

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

Перепрошивка IPMI
Модуль удаленного управления (IPMI / iLO / iDrac) — один из важнейших элементов сервера. Он представляет из себя независимый микрокомпьютер, работающий всегда, когда на материнской плате присутствует рабочее напряжение.

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

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

Перепрошивка BIOS
Базовая система ввода-вывода помимо уже перечисленной причины безопасности требует обновления еще для одного важного момента. В прошивке BIOS имеются микрокоды процессоров, поддерживаемых материнской платой, а также микрокоды сетевых интерфейсов и чипсетов. Когда выходит новая версия процессора, производители материнских плат выпускают новые версии прошивок, которые содержат требуемый микрокод. Без этого новый процессор просто не сможет запуститься. Вместе с прошивкой BIOS зачастую обновляются и связанные модули, например, Intel® ME (Management Engine).

Помимо этого, выпуск новых прошивок предотвращает конфликты, возникающие при взаимодействии различных комплектующих (как встроенных в материнскую плату, так и сторонних устройств).

Дабы не быть голословными, приведем пример. Возьмем материнские платы Supermicro X10SRi/X10DRi/X10DRW, которые поддерживают процессоры Intel® Xeon® E5-XXXXv3. Если поставить туда процессор следующей версии E5-XXXXv4 плата стартует, однако будет выдавать странные ошибки сбоя оперативной памяти «Failing DIMM» в разных слотах. И проблема тут вовсе не в памяти, а в том, что контроллер памяти находится в процессоре. Следовательно, неверное опознавание процессора материнской платой ведет к тому, что возникают подобные проблемы. Перепрошивка с помощью поддерживаемого процессора полностью решает эту ситуацию.

В некоторых случаях производители оборудования искусственно прекращают поддержку новыми моделями материнских плат более старого оборудования. Ярким примером может служить материнская плата Supermicro X11DPi, которая с любой версией прошивки BIOS не будет работать с HBA-контроллерами Adaptec 7-ой серии. Дисковый контроллер просто не инициализируется, вызывая полное зависание сервера. И на данный момент эта проблема не имеет решения.

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

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

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

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

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

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

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

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

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

Нагрузочное тестирование для процессоров Intel проводится с помощью оригинальной утилиты Intel IPDT (Processor Diagnostic Tool). Этот процесс вызывает повышение температуры процессора до максимально допустимой эксплуатационной температуры, и система охлаждения должна эффективно отводить все это тепло. Инженеры сборочной постоянно следят за тем, чтобы сервер прошел это испытание, и температура всех компонентов не превышала заявленных эксплуатационных пределов.

После завершения тестирования проверяются параметры S.M.A.R.T. всех установленных дисков. Если хотя бы один параметр, заявленный производителем как повод для замены накопителя, имеет ненулевое значение, диск заменяется на другой и также тестируется для исключения вероятности возникновения проблем в «боевом режиме».

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

Текущий 2018 год интересен тем, что чуть ли не каждый месяц появляется информация о новых аппаратных уязвимостях: Spectre и Meltdown. Совсем недавно — 2 недели назад! — были опубликованы громкие новости об уязвимостях Foreshadow и L1Terminal Fault, которые, как сообщается, могут обойти даже механизм SGX (Sofware Guard Extensions), которые ранее считался практически невзламываемым. Насколько опасны эти уязвимости? Можно ли от них защититься и если можно, то как? Обо всём этом мы поговорим ниже.

Краткая справка
Foreshadow, или L1TF — это целая группа уязвимостей, в которую входят:

• CVE-2018-3615 — для обхода SGX;
• CVE-2018-3620 — для атаки на ядро операционной системы, а также на режим SMM (System Management Mode);
• CVE-2018-3646 — для атаки на виртуальные машины.

Авторы многих публикаций высказывают особую тревогу в связи с возможностью обхода защиты SGX: этого не умели Spectre и Metldown, и это делает беззащитными любые конфиденциальные данные. Чтобы понять, насколько эта тревога обоснована, разберём принципы работы механизма SGX.

Что такое SGX и как его можно обойти
Аббревиатура SGX означает Software Guard Extensions. Так называется набор инструкций процессоров Intel, используемых для выделения приватных областей кода и данных. В 2015 году один из создателей SGX Мэттью Хойкстра (Matthew Hoeskstra) опубликовал статью (см. также русский перевод), в которой выделил следующие цели создания этой технологии:

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

В процитированной статье маркетинга гораздо больше, чем технических подробностей. В ней рассказано в общих чертах о том, ЧТО позволяет делать технология SGX, но нет ни слова о том, КАК это делается. Об этом мы подробно расскажем ниже. В своём изложении мы будем в первую очередь опираться на подробную статью, опубликованную Международной организацией исследований в области криптологии (IACR, International Association for Cryptologic Research).

SGX создаёт в памяти защищённый регион — PRM (Processor Reserved Memory), который также называют анклавом. Процессор защищает анклав от любых попыток доступа, в том числе и со стороны ядра, гипервизора и SMM (System Management Mode), а также от попыток доступа со стороны периферийных устройств.

У PRM есть специальный кэш, так называемый EPC (Enclave Page Cache), который состоит из четырёхкилобайтных страниц, хранящих код анклава и данные. При вызове доверенной функции приложение «видит» только данные анклава; любой внешний доступ, в том числе и со стороны ОС, запрещён.

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

Как отмечено в официальных публикациях Intel, SGX может защищать от разного рода атак на данные и код: как со стороны системного и пользовательского ПО, так и со стороны загрузчика. А вот от так называемых side-channel-атак SGX защитить не может. Обойти SGX не могут и пресловутые Spectre и Meltdown.

Однако в последнее время появились атаки (собственно, ещё до Foreshadow — см., например, здесь), которые позволяют обходить защиту SGX. Причём Foreshadow — это всего лишь самая громкая и нашумевшая из них.

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

Ещё весной этого года появилась информация об атаке под названием SGX Spectre, с помощью которой можно извлекать данные из анклавов. Как показали исследователи из университета штата Огайо (см., например, здесь), это возможно благодаря «дырам» в SDK, с помощью которых разработчики могут интегрировать поддержку SGX в свои приложения. В числе затронутых SDK оказались Intel SGX SDK, Rust-SGX и Graphene-SGX. С детальным разбором этой атаки можно ознакомиться в этой статье; на Youtube также было опубликовано видео с наглядной демонстрацией примера.

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

Foreshadow нарушает изоляцию, используя так называемую атаку по стороннему каналу (side-channel attack).

Как и в пресловутых Spectre и Meltdown, уязвимость использует механизм спекулятивного исполнения команд. В её основе лежит следующий момент: при доступе к памяти по виртуальному адресу, приводящему к исключению (terminal page fault) из-за отсутствия флага Present в таблице PTE (Page Table Entries), процессоры Intel® спекулятивно рассчитывают физический адрес и загружают данные, если они имеются в L1-кэше. Спекулятивные расчёты осуществляются до проверки наличия данных в физической памяти и до проверки доступности этих данных для чтения. Если флага Present в PTE нет, то операция отбрасывается; но данные при этом «оседают» в кэше и могут быть из него извлечены. Данные могут быть извлечены абсолютно по любому физическому адресу; это открывает обширные возможности для злоумышленников и позволяет, например, извлечь данные на хосте из гостевой машины. Видео с демонстрациями уже появились:

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

Чего бояться?
В отличие от нашумевших Spectre и Meltdown, Foreshadow угрожает только процессорам Intel. В описаниях отмечается, что с помощью этой атаки можно извлечь из анклава не просто конфиденциальные данные, но и приватный ключ аттестации, что подрывает доверие ко всей SGX-экосистеме.

Различные вариации Foreshadow угрожают так называемому System Management Mode (SMM), ядру операционной системы гипервизоров. Некоторые эксперты отмечают, что с помощью Foreshadow можно воровать данные из виртуальных машин в стороннем облаке. Есть публикации, где отмечается, что новая атака даже позволяет обойти патчи, вычисленные ранее для защиты от атак Spectre и Meltdown.

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

На текущий момент действительно серьёзных атак зафиксировано не было.

Патчи и производительность
Тема патчей, защищающих от аппаратных уязвимостей (а если не защищающих, то нивелирующих их последствия), тоже очень актуальна. Вспомним недавнюю историю со Spectre и Meltdown: многие меры были приняты в пожарном порядке, что привело к не самым лучшим последствиям: внезапные перезагрузки системы, резкое падение производительности и т.п. Компании Microsoft пришлось даже выпустить обновления, отключающие патчи Intel. За первые три месяца текущего года только против Intel было подано 32 судебных иска.

На публикацию информации об уязвимости Foreshadow крупные компании отреагировали оперативно: с соответствующими заявлениями выступили Intel, Red Hat, SUSE, VMware, Oracle. Не менее оперативно были выпущены обновления для продукции Cisco и для ядра Linux.

Не обошлось и без казусов: компания Intel быстро выпустила обновления микрокода, но при этом без странных казусов: неожиданно был провозглашен запрет на публикацию результатов тестирования производительности до и после обновления (потом, правда, запрет был отменён). Что это было — сказать сложно. А тема влияния патчей на производительность несомненно заслуживает отдельного исследования и отдельной статьи. И не исключено, что такую статью мы в ближайшем будущем опубликуем.

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

• разъяснение устройства приложений с использованием SGX (см. также русский перевод);
• разбор особеннностей механизма SGX (в том числе и его слабых мест);
• специальный сайт, посвящённый уязвимостям из группы Foreshadow;
• обзор техник атаки на SGX.

Группа компаний Assist — ведущий российский разработчик и интегратор платежных решений. Уже 20 лет компания сотрудничает с мировыми и российскими платежными системами, имеет необходимые сертификаты безопасности. Клиенты группы компаний Assist — тысячи компаний и сотни тысяч конечных пользователей, которые работают в разных часовых поясах, поэтому все информационные системы функционируют в режиме 24/7/365. Сегодня мы расскажем о том, как перенести CRM-систему в облако.

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

Группа компаний Assist является давним клиентом Selectel и размещает стойки с собственным оборудованием в дата-центре на Цветочной улице. На серверах размещаются информационные системы, которые непосредственно связаны с обработкой платежных транзакций. Стойки размещены в соответствии со стандартами PCI DSS и ежегодно проходят внешний аудит соблюдения безопасности.

В условиях современного рынка одним из инструментов, позволяющих увеличить скорость и качество работы с клиентами и учесть все нюансы процесса продаж, является эффективно функционирующая CRM-система. Все данные, обрабатываемые компанией в процессе продаж, не регулируются стандартами PCI DSS, поэтому группа компаний Assist решила рассмотреть проект миграции CRM-системы в облачную инфраструктуру Selectel.

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

Именно поэтому директор по эксплуатации, Кирилл Иванов, сделал ставку на оптимизацию эксплуатационных расходов и снижение рисков. Он решил проработать проект переезда одной из информационных систем к облачному провайдеру, осуществив перенос ответственности за инженерное и вычислительное оборудование на компанию-провайдера. «CRM-система, работающая в режиме 24/7/365, очень важна для нас, мы поставили себе задачу изучить возможность повышения отказоустойчивости и масштабируемости путем миграции в облако», — вспоминает Кирилл Иванов.

Почему Selectel
Группа компаний Assist сформировала набор требований, которым должен был удовлетворять IaaS-провайдер:

• российская компания;
• надежный поставщик;
• территориально распределенное облако;
• легкая масштабируемость инфраструктуры;
• инфраструктура как код (IaC);
• наличие сертификатов и лицензии ФСБ и ФСТЭК;
• возможность получить аттестацию для соответствия 152-ФЗ.

«В соответствии с законом 152-ФЗ о персональных данных — информация о клиентах и партнерах должна быть размещена на территории РФ в дата-центрах, имеющих необходимые лицензии и сертификаты. Заниматься этим самим — дорого и долго», — говорит Кирилл Иванов.

Желание использовать облачные сервисы Selectel было продиктовано стратегией консолидации набора сервисов у одного поставщика:

• удобство администрирования всех ресурсов;
• единый способ оплаты услуг;
• общая круглосуточная техническая поддержка всех сервисов.

Архитектура решения
Разрабатывая концепцию облачного переезда, инженеры решили создать отказоустойчивую инсталляцию (кластер) в виде нескольких разнесенных инстансов серверов приложений и СУБД MySQL. Хранение всех вложений CRM-системы: файлов коммерческих предложений, реквизитов компаний, текстов и копий договоров, счетов, актов — было решено вынести во внешнее облачное хранилище.


Тонкости подключения
Облачные ресурсы Selectel, на которых развернуто решение Битрикс CRM группы компаний Assist, находятся в одном из шести дата-центров компании Selectel — в поселке Дубровка, Ленинградской области. Причем для реализации отказоустойчивости используются два разных независимых пула «Виртуального приватного облака» с трехкратным резервированием на разных серверах и подключением к разному сетевому оборудованию, разным СХД, в разных стойках.

Так как основное серверное оборудование группы компаний Assist находится в Санкт-Петербурге, возник вопрос создания дополнительного защищенного канала до дата-центра в Дубровке для безопасного доступа к CRM-системе. С точки зрения заказчика, это дополнительные расходы на оплату канала связи и его защиту. Сотрудники Selectel предложили альтернативный вариант с VLAN-VPAN подключением облачных ресурсов к имеющемуся оборудованию группы компаний Assist с учетом трехкратного резервирования канала связи. Предложенная альтернатива существенно снизила расходы на организацию защищенного канала к CRM-системе и повысила надежность подключения.

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

Еще 2 месяца ушло на создание пилотных инсталляций, развертывание сервисов и тестирование. После успешно пройденных нагрузочного тестирования и стресс-тестов, имитирующих отказ части инстансов, был согласован срок переноса CRM-системы группы компаний Assist в облачную инфраструктуру Selectel и запуск в эксплуатацию. В общей сложности от возникновения идеи «А не переехать ли нам в облако?» до запуска прошло всего 6 месяцев.

Гибридная IT-инфраструктура
Несмотря на то, что группа компаний Assist перенесла одну из своих систем в облако, компания реализовывает гибридный вариант использования услуг IaaS-провайдеров.

• Для собственного оборудования, на котором установлены системы, обрабатывающие платежные транзакции, компания выбрала услугу
• «Размещение серверов».
• CRM-систему компания перенесла в облачную инфраструктуру Selectel, выбрав «Виртуальное приватное облако».
• Файловое хранилище группа компаний Assist вынесла в отказоустойчивое «Облачное хранилище» с резервированием на стороне AWS.

«За счет переезда в облако мы осуществили консолидацию ресурсов и поставщиков, поскольку уже используем Selectel в других проектах. Теперь все наши сервисы мы получаем у одного поставщика. Мы имеем возможность легкого, быстрого и практически неограниченного масштабирования по ресурсам», — добавляет Кирилл Иванов.

В качестве итога
После переноса в облако CRM-система безостановочно работает уже третий месяц. «Финансовый результат от привлечения новых клиентов или увеличения объемов продаж старым клиентам в таком кратком периоде оценить, конечно же, сложно. Прямой экономический эффект от миграции — снижение эксплуатационных расходов минимум на 30%, — комментирует Кирилл Иванов, — Одна из основных причин, которая побудила нас к переезду — нежелание поддерживать старое и покупать новое железо. Всю инфраструктурную часть проекта мы отдали облачному провайдеру».

Только что услышали внутри, что мы увеличили наши операций ввода-вывода на OVH PublicCloudс x20 раз, благодаря SD NVMe оптимизации.

От описания баланса до отслеживания заказов, кто никогда не получал SMS от компании? В 2017 году французский рынок рекламы A2P (Application to Person) представлял собой объем в 4,5 миллиарда сообщений с увеличением более чем на 20% по сравнению с 2016 годом. Как убедиться, что каждое сообщение достигает своего места назначения?? С 2011 года в рамках своего телекоммуникационного бизнеса OVH предлагает услугу SMS-вещания, которая встречает некоторый успех. И каждый день мы работаем над качеством маршрутов SMS, чтобы мы могли надежно и в кратчайшие сроки доставлять сообщения наших клиентов.


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

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

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

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

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

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



Другая широко используемая услуга OVH — это платформа Metrics. Действительно, мы разработали большое количество прикладных зондов, в основном через публичную библиотеку ovh-go (https://github.com/ovh/go-ovh), что позволяет нам тестировать наши разъемы и с течением времени.

Например, через регулярные промежутки времени в СМС OVH API запускается пробник. В свою очередь, мы подтверждаем, что возврат этого вызова согласуется с тем, что он должен быть, чтобы обнаружить возможную регрессию или инцидент, но также и время, когда платформа вернет эту информацию. Все эти значения отправляются через протокол OpenTSDB в Metrics, что позволяет нам синтезировать их и отслеживать их эволюцию с течением времени.



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



Что касается пропускной способности, наша инфраструктура рассчитана на 1000 SMS / секунду. Массивная маркетинговая кампания в 500 000 SMS проглатывается и переваривается менее чем за десять минут. В случае кампании, инициированной в течение периода занятости, система очередей и приоритизации позволяет нам продавать обычный трафик, вставляя его среди SMS кампании. Мы отслеживаем среднее время доставки SMS на каждом из наших маршрутов с целью до 10 секунд для получения SMS и возврата подтверждения.

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

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

Дело в том, что мы даже отклонились от нашего же плана развития проекта, описанного в конце этой статьи

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

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

Данный инфо-пост поставит начало дальнейшему движению, а оно уже началось, поверьте. Обновление дизайна группы (если кто-то заметил) и закрытые тикеты — это лишь малая часть, но мы хотим показать, что проектом занимаемся. У всех пользователей вчера были закрыты тикеты (а многие даже без ответа) в нашей группе, тому причиной стало усовершенствование системы тикетов и включение в команду новых сотрудников, с которыми мы сможем хоть и не моментально, но в течение 10-60 минут реагировать на ваши запросы. Что касается сроков выдачи — сейчас это по-прежнему составляет ~48ч на виртуальные и выделенные серверы и ~60 сек на виртуальный хостинг, однако уже в самом ближайшем будущем планируется сократить сроки выдачи до ~24ч, а максимальные до 72 часов.



Спасибо, кто остается с нами. Вы лучшие!
cloudtree.me/index

Добавьте мощностей своему проекту, разместив его на выделенном сервере с процессорами последнего поколения — Intel Xeon Scalable. Заказывайте на 1dedic.ru:


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

• Повышена производительность ядер
• Увеличена скорость работы с оперативной памятью
• Полноценная поддержка скоростных накопителей NVMe — в 3 раза быстрее SSD
• Построение распределенных систем и RAID-массивов без стороннего оборудования и ПО
• Scalable в 1,5 раза быстрее процессоров предыдущего поколения (E5v4)
• Подробнее обо всём этом в новости на сайте

Нам кажется, что переход на сервер Scalable с NVMe — один из самых простых способов увеличить производительность проекта.

А ещё мы обновили конфигуратор — собирать новый сервер стало удобнее. Подбирайте параметры своего сервера, сравнивайте с другими платформами. Новые Scalable доступны в формате двухпроцессорных серверов, цены начинаются от ~11 т.р. в месяц.

А ещё мы обновили конфигуратор — собирать новый сервер стало удобнее. Подбирайте параметры своего сервера, сравнивайте с другими платформами. Новые Scalable доступны в формате двухпроцессорных серверов, цены начинаются от ~11 т.р. в месяц.


1dedic.ru

vdsina.ru/quest/
vdsina.ru/?partner=1374

К сожалению мы были вынуждены отложить провождение планированных технических работ для В нашем датацентре на 26 сентября С 08:00 По 09:00 (по МСК)

Ожидается перерывы связи в общей сумме до 30 минут для следующих услуг:
Linux HDD VPS
Windows VPS
Выделенные серверы
Услуги колокации
(Linux SSD VPS не будут затронуты)
Сами серверы и данные на них не будут затронуты.
Вы можете следить за процессом технических работ здесь: secure.veesp.com/status/

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

Первый совет это перейти на PHP версии 7 или выше. Много тестов показали что PHP7 работает намного быстрее чем PHP5. В версии PHP7 было внесено много изменений и усовершенствований.
Что-бы сменить версию PHP вам необходимо всего лишь зайти в свой хостиг аккаунт и перейти в раздел WWW -> PHP в котором выбрать версию PHP по умолчанию. Затем, выбрать нужный вам домен и сменить ему версию PHP. Ваши сайтымогут работать с PHP как модуль Apache и как CGI. После смены версии PHP сайт автоматически перейдет на работу с выбранныой версией.

Следующий совет это кеширование отдачи сайта через прокси CloudFlare www.cloudflare.com Наш хостинг поддерживает интеграция с CloudFlare.
Вам необходимо ввести логин и пароль от CloudFlare в панели хостинга в разделе Инструменты -> CloudFlare.
После этого вы можете выбрать любой ваш сайт переключить его на работу с CloudFlare всего в один клик.

bill.conturov.net/manager/billmgr?func=register