Это вторая часть серии блогов, вот и первая. Ранее мы обнаружили, что бастион не является вашим обычным SSH-хостом jumphost (на самом деле, мы обнаружили, что это вообще не Jumphost), и обсудили, как делегирование было одной из основных функций, которые нам изначально нужны. Итак, давайте углубимся в эти концепции. На бастионе есть две совместимые модели доступа: персональный и групповой.


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

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

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

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

Групповой доступ — Let's Rock
Группа состоит из трех компонентов:

• Список участников (аккаунты, представляющие отдельных людей)
• По крайней мере, один набор групповых выходных ключей
• Список серверов (фактически IP)

Список серверов
Список серверов на самом деле представляет собой список IP-адресов или IP-блоков. Они сопоставляются с вашими серверами, сетевыми устройствами или чем-либо еще с поддержкой SSH, имеющим IP-адрес (на котором был установлен ключ исходящей группы). Технически этот список состоит из трех элементов: удаленный пользователь, удаленный IP (или блок IP), удаленный порт. То, что относится к личному доступу, также применимо и здесь: добавление сервера в список не дает ему доступа волшебным образом, сначала необходимо установить открытый ключ исходящей группы. Конечно, управление установкой этих ключей вручную быстро становится непрактичным, но вы можете рассмотреть эту часть конфигурации серверов, поэтому ими следует управлять с помощью той централизованной системы конфигурации, которую вы уже используете (Puppet, Chef, Ansible, / bin / cp… подожди, нет, ударил последний).

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

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

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

• Гости
• Привратники
• Aclkeepers
• Владельцы

Все это списки учетных записей, играющих определенную роль в группе.

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

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

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


Глобальные роли — Приходите получить
Помимо только что описанных ролей, которые относятся к группе, существуют две дополнительные роли, охватывающие весь бастион: «супервладелец» и «администратор бастиона».

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

Головокружение еще не закончилось? Теперь о самой влиятельной роли: админке бастиона. Эта роль должна быть предоставлена ​​только нескольким лицам, поскольку они могут выдавать себя за кого угодно (даже если, конечно, когда они это делают, это регистрируется и заставляет наш SIEM покраснеть), и на практике не следует отдавать никому, кто еще не получил root-права в самой операционной системе бастиона. Помимо прочего, они управляют конфигурацией бастиона, где объявлены супервладельцы. Задержи дыхание. Готов? Им разрешено давать право давать право давать право давать право доступа. Вот почему делегирование лежит в основе системы: у каждого есть свой набор обязанностей и потенциальных действий, без необходимости спрашивать администратора бастиона.

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


Как вы могли заметить на скриншоте выше, версия программного обеспечения Bastion очень близка к 3.00.00! Может быть, приближается интересная веха?

В следующей части этой серии блогов мы рассмотрим некоторые детали реализации одного из этих плагинов osh, а точнее, наш подход к программированию безопасности и защиты.

Чтобы помочь нашим мексиканским клиентам, мы подключили 2 новых PNI к Telmex (AS8151) — 2x10G в Далласе и 2x10G в Лос-Анджелесе.

bhs.smokeping.ovh.net/smokeping?filter=8151;target=SA.AS8151

В общей сложности емкость 400G.
gra.smokeping.ovh.net/smokeping?filter=Hetzner;target=EMEA.AS24940-1

В сети OVHcloud 34 точки присутствия (PoP); расположены в Европе, Северной Америке и Азиатско-Тихоокеанском регионе. Обладая глобальной пропускной способностью около 21 Тбит/с, сеть OVHcloud может обрабатывать гораздо больше трафика, чем другие провайдеры.

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

В течение последних нескольких лет OVHcloud работал над улучшением инфраструктуры нашей всемирной магистральной сети.



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

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

Обеспечение максимально возможной связи для наших клиентов по всему миру было движущей силой компании с момента ее создания Октавом Клаба. Для этого мы хотели быть максимально подключенными к местным провайдерам, для чего требовалось несколько портов со скоростью 10 или 100 Гбит/с.

Переосмысливая топологии PoP, мы рассмотрели новые масштабируемые технологии, в том числе:

• Пропускная способность порта: должна быть основана на портах 100 Гбит / с и 400 Гбит / с и иметь хорошую экономическую эффективность. Это поможет устранить любые узкие места в сети. Также необходимо было поддерживать каналы 10 Гбит / с для тех провайдеров, которые не были готовы к портам 100 Гбит / с.
• Легко обновлять: новую архитектуру нужно было легко модернизировать с точки зрения емкости. Частично это сделано для роста компании, но также для поддержания доступности, когда на PoP требуется обслуживание сети.
• Мощность: команде нужно было найти лучшее оборудование для максимального повышения эффективности энергопотребления; особенно в таких странах, как Сингапур, где это дорого.
• Безопасность: ключевым требованием будет работа с нашими группами безопасности, чтобы найти лучшее решение для защиты сети от угроз (массовых DDoS-атак).

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

Обзор SMAUG


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

Инфраструктура Spine and Leaf
SMAUG — это инфраструктура «Spine and Leaf». Это означает, что «позвоночник» (называемый SBB от SuperBackBone) объединяет листья и соединяет каждый центр обработки данных. «Листовые» устройства (называемые PB для PeeringBox) используются для подключения провайдеров, а также внутренних служб, таких как оборудование xDSL или OVHcloud Connect.

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

Чтобы обеспечить избыточность, оба PoP должны быть подключены друг к другу с огромной пропускной способностью — в 100 Гбит / с или 400 Гбит / с, в зависимости от PoP. Группа по передаче электроэнергии также участвовала в разработке новой инфраструктуры под названием «ГАЛАКТИКА». GALAXY была основана на другом конструкторе — в сочетании с простой в развертывании, масштабируемой, операционной моделью с меньшим энергопотреблением.

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

Роль позвоночника более сложная и имеет дополнительные функции, в том числе:

• Соединения дальнего следования: он обеспечивает соединение каналов на основе 100 Гбит / с к центрам обработки данных и PoP.
• Маршрутизация: в нем есть вся таблица маршрутизации, чтобы выбрать лучший путь к центрам обработки данных OVHcloud или к внешним сетям.
• Защита: команда VAC участвовала в разработке нового инструмента защиты (для получения дополнительной информации: www.ovh.com/blog/using-fpgas-in-an-agile-development-workflow/) в порядке чтобы помочь защитить всю сеть OVHcloud от DDoS-атак.
• Смягчение: это также помогает системе обнаружения, используемой инфраструктурой VAC www.ovh.co.uk/anti-ddos/

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

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

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

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

Переход на SMAUG
Давление на то, чтобы этот переход был успешным, был высоким, поскольку мы не хотели, чтобы он повлиял на наших клиентов. В первую ночь миграции — когда мы исчерпали трафик от первого PoP — мы попросили технических специалистов переместить все дальнемагистральные каналы в Сингапурский округ Колумбия, а для Австралии, Франции и США — на новые устройства. После некоторых тестов мы запустили новые устройства в производство. Первый шаг миграции прошел хорошо.

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

В последний день миграции наша группа по передаче данных внедрила еще одну технологию. Целью здесь было увеличить пропускную способность между сингапурским центром обработки данных и точкой доступа, где мы установили эти новые устройства. После того, как мы изолировали трафик между обоими концами, мы переместили темное волокно в новую оптическую систему DWDM (Galaxy), чтобы добавить 400 Гбит / с пропускной способности центру обработки данных. Поскольку это было ново, у нас возникли проблемы с объяснением, как исправить некоторые проблемы с кабелями в системе. После того, как все было исправлено и готово, мы запустили 4 канала по 100 Гбит / с в производство.

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

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


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

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

Спасибо командам и отраслевым партнерам, которые помогли создать эту новую инфраструктуру.

GAIA-X — это проект, инициированный Европой для Европы. Многие страны работают вместе, чтобы стимулировать появление надежного альтернативного облака в Европе. В его состав входят 22 члена-учредителя, в том числе крупные организации, интеграторы и ведущие поставщики облачных услуг Европы. OVHcloud и ассоциация CISPE входят в число этих членов.

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

На совместной пресс-конференции, проведенной министрами экономики Франции и Германии, наш генеральный директор Мишель Полен объяснил:

Для OVHcloud поддержка разработки GAIA-X является очевидным выбором. Защита данных, открытые стандарты, обратимость и прозрачность — все это европейские ценности, которые составляют ключевую часть идентичности OVHcloud. Они также являются основными ценностями GAIA-X

www.data-infrastructure.eu/GAIAX/Navigation/EN/Home/home.html

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

Представляем наши новые PaaS-решения для обработки данных:
Большинство предприятий используют данные, чтобы получить представление о клиенте и решить бизнес-проблемы. Тем не менее, адаптация существующей инфраструктуры для обработки больших объемов данных и развертывания моделей ML вызывает операционные головные боли и высокие расходы.

В ответ компания OVHcloud представила два новых решения PaaS, нацеленных на упрощение обработки данных, их простоту развертывания и высокую масштабируемость. Эти общедоступные облачные решения предоставляют ресурсы с оплатой по факту и лучшее соотношение цены и производительности на рынке:

Обработка данных OVHcloud: Выполните все свои задания по обработке данных (включая проекты больших данных), используя кластеры Apache Spark, развернутые по требованию.
www.ovhcloud.com/en-ie/public-cloud/data-processing

Обслуживание OVHcloud ML: Быстрое развертывание моделей машинного обучения в производстве с использованием каталога предварительно обученных моделей или ваших собственных.
www.ovhcloud.com/en-ie/public-cloud/machine-learning-serving/

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

Чтобы узнать больше, посетите наш веб-сайт www.ovhcloud.com/en-ie/ Чтобы узнать больше о наших решениях Data Analytics и AI, вы также можете посмотреть это видео-интервью, чтобы узнать, как мы включили Systran, программное обеспечение для перевода на основе AI.

Развернуть > 100 стоек в APAC в ближайшие месяцы :)

Представьте себе 24 жестких диска, подключенных в 1 корпусе к AMD Epyc Rome2. Представьте себе кластерный объектный блок NFS, основанный на 9 стойках по 24 сервера, каждый с 24 дисками по 15 ТБ.

T3-96-6KW-З

• 96 серверов в стойку с 6 кВт
• с 4 уровнями стоек у нас есть 384 сервера типа ADV-1/2/3
• Все серверы с водяным охлаждением.
• PUE = 1,07
• Это означает всего лишь 7% потерь энергии!