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

А еще мы знаем, как избавиться от этих трудностей, и хотим поделиться решением с вами. Приглашаем вас на бесплатный вебинар, где расскажем, как с помощью управляемых баз данных в облаке забыть о долгой настройке БД и сфокусировать силы команды на разработке продукта. Вы узнаете, как создавать масштабируемые кластеры баз данных в несколько кликов, планировать бюджет на БД и сокращать расходы на развертывание инфраструктуры.
promo.selectel.ru/webinars/dbaas/170620/

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

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

Присоединяйтесь к нам 17 июня 2020 года с 10:00 до 11:00 для нашего следующего вебинара, на

• котором мы рассмотрим следующие вопросы безопасности:
• Советы по созданию основанного на риске подхода к популярным атакам
• Как разработать меры безопасности для минимизации рисков
• Как интегрировать безопасность в ваш подход к переходу в облако

Кто должен присоединиться к этому вебинару?

• Люди, желающие узнать больше об ИТ-безопасности
• Владельцы бизнеса, обеспокоенные безопасностью своей ИТ-инфраструктуры
• Менеджеры ИТ-инфраструктуры недавно увеличили размер своей инфраструктуры

Кибератаки могут поставить под угрозу весь ваш бизнес, узнать, как защитить свой бизнес и его инфраструктуру!



register.gotowebinar.com/register/8316537034901278222?source=Canada

Несколько лет назад сервис онлайн-бронирования отелей Ostrovok.ru перевел инфраструктуру с облака Amazon Web Services на серверы Selectel. Издержки миграции окупились за месяц, а стоимость хостинга уменьшилась в два раза. В рамках фестиваля «Российские интернет-технологии-2020» руководитель отдела инфраструктуры сервиса Денис Божок рассказал о причинах переезда, архитектурных ограничениях и старом добром heavy bare-metal.

О выборе Amazon Web Services
До переезда мы жили на паре десятков серверов в маленьком дата-центре и четкого плана по переходу на облачные платформы у нас не было. Но с ростом числа отелей на сайте росло и количество их фотографий. К 2014 году объем визуального контента составлял порядка 4-5 терабайт.

Для дальнейшего роста нужно было думать над масштабированием хранилища фотографий, искать удобные инструменты для их хранения и резервирования. Тогда и пришла мысль попробовать решение от AWS — его легендарное S3 хранилище.

Дата-центры Amazon расположены более чем в 20 регионах по всему миру. В Европе на данный момент выделено пять регионов — Милан, Париж, Лондон, Франкфурт и Ирландия.

Об отсутствии необходимых сервисов
Шесть лет назад мы «заезжали» в регион Франкфурт. На тот момент он был молодым, и все сервисы, уже внедренные в более зрелых регионах, до него доходили с задержкой. Не раз бывало, что нам нужен был функционал сервиса, которого либо не было совсем, либо он отсутствовал в нашем регионе.

Например, в наш регион завезли спотовые инстансы — аукцион серверных мощностей, благодаря которому можно сэкономить до 90% их стоимости. Но инструментов, позволяющих настроить автоматический заказ нужных серверов, не было. Приходилось заходить в консоль аукциона, выбирать тип инстанса, устанавливать цену, добавлять новые «виртуалки» в кластер. Неэффективная трата времени и высокий шанс упустить изменение цен. Поэтому мы создали свой менеджер спотов, который заказывал нужные серверы по подходящим ценам и сам добавлял их в кластер. Аналогичный инструмент — spot fleet — на Amazon Web Services появился лишь спустя несколько лет.

Точно так же нам пришлось оптимизировать работу с системой управления базами данных DynamoDB от AWS. Одна из ее фишек в том, что ты платишь за IOPS (количество операций ввода-вывода в секунду) и сам можешь выставлять лимиты по операциям. Это удобно, но, опять же, не было автоматизированного управления. Поэтому мы разработали собственный механизм, который выставлял подходящие нам лимиты IOPS и регулировал их по мере необходимости.

Кроме того, долгое время в AWS не было удобных инструментов для работы с Docker, которым мы уже активно пользовались. Поэтому до появления подходящих нам сервисов на Amazon Web Services справлялись своими силами.

В целом, не могу назвать перечисленные ситуации критичными. При переходе из облака на решения on-premises будьте готовы, что многие процессы, выполняемые ранее облачным провайдером, перейдут в вашу зону ответственности. Идеальное решение — то, что максимально подходит под ваши требования и особенности компании.

О причинах переезда
В 2016 году мы задумались о смене провайдера и начали поиск на российском рынке. Причин для переезда c облака от Amazon было несколько.

Во-первых, мы хотели оптимизировать расходы. Все-таки AWS, несмотря на относительное удобство, стоит немалых денег. Мы понимали, что можем эффективнее использовать наши ресурсы. Кроме того, нам нужно было следовать № 152-ФЗ, который требует хранения персональных данных на территории России.

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

Нас это устроило, взяли курс на миграцию — с облака в «железо».

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

Справедливости ради добавлю, что фотографии, из-за которых мы изначально пришли в Amazon Web Services, пока остались там же, в S3 хранилище. Объем фотографий с 2014 года вырос до 70 терабайт. Все остальное — базы с персональными данными, поисковые кластеры и служебные сервисы — мы перевезли. В планах есть окончательная миграция, но это операция непростая.

О «граблях»
Тут могу сказать одно: у каждого будут свои «грабли». И это нормально. Главное — понимать цель переезда.

Мы столкнулись с многими архитектурными ограничениями. Так, нам нужно было настроить общую сеть между физическими серверами и нашими VPC (Virtual Private Cloud, «виртуальное частное облако») в Облачной платформе Selectel. На VPC мы переносим сервисы, которые неприхотливы к объему ресурсов. Например, кластер DNS-серверов у нас расположен в частном облаке — удобно и надежно. Иногда можем развернуть какой-нибудь тест на VPC, удалив облако по завершении задачи.

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

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

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

О старом добром heavy bare-metal
Конечно, будь инфраструктура в облаке, со многими описанными проблемами мы бы не столкнулись. Но после цикла «железо-облако-железо» пришли к выводу: для Ostrovok.ru нет ничего лучше старого доброго heavy bare-metal.

Проблема любого облака — vendor lock-in, или привязка к поставщику. Если кратко, ты подсаживаешься на облачные сервисы, того же Amazon, и теряешь свободу передвижений. Например, съехать с Relational Database Service (база данных от Amazon) на свою «ламповую» базу данных без простоя очень проблематично.

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

Выбор «железа» — наше решение, обусловленное опытом и особенностями работы компании. У нас и разработка, и релизы достаточно предсказуемы. Когда на Ostrovok.ru ожидается рост из-за сезонности или маркетинговых акций, мы заранее обеспечиваем рост количества серверов. Либо скидываем лишние, если нагрузка снижается.

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

Иностранная построена на простой логике: хочешь поддержку — плати деньги. Хочешь быструю поддержку — плати еще больше денег. Кроме того, на AWS приходилось оплачивать поддержку для каждого нашего аккаунта — одна подписка на несколько, даже сопряженных, не распространялась.

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

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

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

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

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

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

Если вы задумались о смене провайдера хостинг-услуг, вот на что стоит обратить внимание:

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

Текст написан на основе открытого интервью Дениса Божок с архитектором облачных решений Selectel Романом Тимофеевым. Интервью состоялось в рамках онлайн-фестиваля «Российские интернет-технологии-2020» 26 мая.

Ostrovok.ru – сервис онлайн-бронирования отелей. Компания предоставляет клиентам более 1 300 000 вариантов размещений в гостиницах, хостелах и апартаментах от прямых поставщиков и крупных партнеров. Входит в Emerging Travel Group, которая управляет четырьмя тревел-брендами: Ostrovok, B2B.Ostrovok, ZenHotels, RateHawk.

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

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

Для тех, кто не нуждается в вечном хостинге, мы предоставляем скидку при оплате хостинга на полгода, всего за 120 рублей!

Для активации скидок, нужно ввести промокод fouryears во время оплаты.
Подробнее о промокодах: blog.chsw.group/2018/11/06/faq-promo.html

Наш телеграм: Bomjarga & CHSW.group
Группа ВК: BOMJAR.ga

Будем признательны, если Вы оставите свой отзыв:
ru.trustpilot.com/review/bomjar.ga

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

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

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

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

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

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

Проектированием таких интерфейсов занимается UX-дизайнер (UX — User Experience, «опыт пользователя»).

Подробнее
selectel.ru/blog/ux-designer/

https://fastvps.ru

В одной из предыдущих статей цикла про гипервизор Proxmox VE мы уже рассказывали, как выполнять бэкап штатными средствами. Сегодня покажем, как для этих же целей использовать отличный инструмент Veeam Backup&Replication 10.

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

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

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


selectel.ru/blog/proxmox-veeam-backup/

Bastion? Мы говорим об инди-игре?
Не в этот раз! (хотя это хорошая игра!).


В OVHcloud довольно много наших инфраструктур построено поверх Linux-боксов. У нас много разных вкусов; такие как Debian, Ubuntu, Red Hat… и этот список можно продолжить. У нас даже был старый добрый Gentoos однажды! Все они хранятся на голых металлических серверах, на виртуальных машинах и в контейнерах повсюду. Пока у него есть процессор (или vCPU), мы, вероятно, загрузили на него какой-нибудь дистрибутив Linux. Но это еще не все. У нас также были коробки Solaris, которые позже превратились в коробки OmniOS, которые теперь превратились в блестящие коробки FreeBSD. У нас также есть много сетевых устройств, разделенных на разных конструкторов, охватывающих широкий спектр поколений моделей.

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

Проблема
Уже давно SSH является стандартом администратора де-факто — он заменил устаревшие программы, такие как rlogin, которые с радостью передавали ваш пароль в незашифрованном виде по сети, — поэтому мы используем его постоянно, как и большинство представителей отрасли.

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

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

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

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

PKI-аутентификация
Ради полноты — потому что я слышу вас отсюда, гуру SSH! — в последних версиях серверов SSH существует третий способ, а именно аутентификация на основе PKI с доверенным центром сертификации (CA). Вы устанавливаете общедоступный сертификат своего CA на всех своих серверах, и они принимают любое соединение, аутентифицированное сертификатом, предоставленным этим CA, полагаясь на имя субъекта сертификата. Это указывает, к какой учетной записи можно получить доступ на сервере, между прочим. Это очень централизованный способ управления вашими доступом со всей властью того, кто контролирует ваш ЦС. Это может быть очень успешным, если сделать это очень осторожно, с большим количеством безопасности и процессов вокруг рабочих процессов доставки сертификатов. Правильное управление ЦС не является шуткой и может привести к серьезным укусам, если вы поступите неправильно. Это также является сравнительно недавним дополнением к OpenSSH, и, учитывая неоднородность, которую мы обрисовали выше, она оставила бы множество систем на стороне. Есть и еще одна причина, по которой мы не выбрали этот метод, но прежде чем углубляться в него, давайте поговорим о наших потребностях.

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

Но как нам удалось разработать системы безопасности на основе управления SSH для всех этих серверов, не мешая различным операционным командам?


Требуется несколько важных вещей:

ДЕЛЕГАЦИЯ

• Любой вид централизованной «группы безопасности», ответственной за обработку разрешений на доступ для всей компании, запрещен. Это не масштабируется, независимо от того, как вы это делаете.
• Менеджеры или технические руководители должны быть полностью автономны в управлении своим собственным периметром с точки зрения серверов / систем / устройств и в отношении тех лиц, которым предоставлен доступ в пределах их периметра.
• Участник команды, переходящий в другую команду или из компании, должен быть полностью цельным процессом, независимо от того, к каким системам этот человек имел доступ (помните гетерогенность выше?).
• Предоставление доступа новому члену команды также должно быть беспроблемным, чтобы они могли испачкать руки как можно быстрее.
• Временное предоставление доступа кому-либо за пределами группы (или компании) к данному активу на ограниченный период времени должно быть легким.
• Все это должно быть сделано автономным

AUDITABILITY & TRACEABILITY

• Каждое действие должно быть зарегистрировано с большим количеством деталей; будь то изменение разрешения или соединение с системой; будь успешным или нет. Мы также хотим, чтобы это было применимо к некоторым SIEM.
• Каждый терминальный сеанс должен быть записан. Да, вы правильно прочитали. Это особенность, которая вам никогда не понадобится… пока вы этого не сделаете.
• Должно быть легко создавать отчеты для проведения проверок доступа.

БЕЗОПАСНОСТЬ И УСТОЙЧИВОСТЬ

• Мы должны обеспечить больше безопасности, чем простой прямой доступ по SSH, без дополнительных затрат.
• Любой компонент, который мы должны добавить для удовлетворения этих потребностей, должен постоянно работать и даже (особенно), когда остальная часть вашей инфраструктуры разваливается, потому что именно тогда вам потребуется SSH.
• Так какова другая причина, по которой мы не выбрали путь PKI? Что ж, это ограничило бы автономию командных групп: только центр сертификации мог бы выдавать или отзывать сертификаты, но мы хотим, чтобы эта власть была в руках командных групп. В случае с PKI, если бы мы хотели дать им некоторую власть, нам пришлось бы реализовать сложную логику вокруг CA, чтобы сделать это возможным, и мы не хотели идти по этому пути.

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

• Администратор хочет подключиться к машине с именем server42
• Он не может напрямую использовать SSH с ноутбука своей компании на сервер42, поскольку сервер42 защищен брандмауэром и разрешает только входящие соединения SSH из бастионных кластеров компании.
• Вместо этого администратор начинает сеанс SSH с бастионом, используя свою именную учетную запись. Его ноутбук согласовывает сессию SSH, используя свой закрытый ключ. Это этап аутентификации: бастион гарантирует, что администратор, представившийся как Джон Админ, действительно является этим человеком, что возможно благодаря тому факту, что открытый ключ Джона Админа находится внутри его учетной записи бастиона. Мы называем это * входной * связью.
• После аутентификации Джона Админа он просит бастион открыть соединение с учетной записью root на сервере42.
• Бастион проверяет, разрешен ли John Admin доступ к корневой учетной записи на сервере42, это часть авторизации. Скажем для примера, что Джону Админу действительно разрешено подключаться к этому серверу, используя закрытый ключ своей команды (подробнее об этом позже).
• Бастион инициирует SSH-соединение с сервером 42 от имени Джона Админа, используя закрытый ключ бастиона своей команды.
• Брандмауэр server42 разрешает входящие SSH-соединения от бастиона, и соединение успешно согласовывается, поскольку открытый ключ бастиона команды John Admin установлен на корневой учетной записи server42. Мы называем это * выходной * связью.
• Теперь у нас есть два установленных SSH-соединения: входное соединение между John Admin и бастионом и выходное соединение между бастионом и сервером42.

Теперь происходит какое-то волшебство, и бастион «соединяет» эти два соединения вместе, используя псевдотерминал (pty) между ними. Теперь у Джона Админа сложилось впечатление, что он напрямую подключен к серверу42 и может взаимодействовать с ним, как если бы это было так.
Между тем, бастион может записывать все, что набрано Джоном Админом (или, точнее, все, что * видит * Джон Админ, мы не будем записывать пароли, которые он вводит на терминалах noecho!), Это обрабатывается с помощью ovh- программа ttyrec.

Чтобы быть совершенно понятным, server42 не знает, кто такой Джон Админ, и не нуждается в этом: мы отделили часть аутентификации и авторизации. Только бастион должен знать и аутентифицировать администратора, а удаленный сервер только знает и доверяет бастиону (или, точнее, команде Джона Админа на бастионе). Это открывает целый ряд возможностей… но об этом подробнее в следующем посте!

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

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

Инициатива GAIA-X обусловлена необходимостью повышения осведомленности о суверенитете данных и создания федеративной надежной облачной экосистемы для Европы.

В этой статье мы обсудим, как группа демонстраторов GAIA-X, состоящая из 3DS OUTSCALE, Docaposte, German Edge Cloud, Orange Business Services, OVHcloud, Scaleway и T-System, создала прототип механизма поиска по каталогам.



Одна из целей поисковой системы каталога состояла в том, чтобы дать пользователю возможность искать и выбирать службы, которые соответствуют его потребностям. Цель состоит в том, чтобы быть инклюзивным и предоставлять информацию пользователю, чтобы он мог сделать прозрачный, образованный выбор. Информация, описанная для каждой услуги, включает, по крайней мере, все соответствующие «Правила политики», определенные руководством GAIA-X как обязательные, и набор технических описаний. «Правила политики» охватывают множество областей (защита данных, безопасность, обратимость и т. Д.) И разработаны в двух документах: один для правил политики инфраструктуры, а другой для правил политики данных и программного обеспечения.

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

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

Например, если клиент запрашивает «базу данных, совместимую с PCI-DSS для платежных услуг, размещенную в Германии в соответствии с Кодексом поведения по защите данных CISPE», интересующими объектами являются «база данных», «PCI-DSS», «Германия» и «Защита данных CISPE».

Но как сущности связаны друг с другом и как они определены? И можем ли мы их классифицировать?

Одним из интуитивно понятных способов представления семантики было использование графиков, подобных приведенным ниже:



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


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

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

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

Мы использовали Gitlab с управляемой интеграцией кластеров Kubernetes и стандартными настройками конвейера CI / CD для развертывания микросервисов. Мы использовали графическую базу данных Neo4j для хранения данных.


С онтологией и таксономией следующим шагом было заполнение базы данных.

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


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

Для продвинутых запросов мы решили не предоставлять язык запросов Neo4j Cypher, а создать еще более простую грамматику синтаксического анализа, основанную на отношениях между узлами и их атрибутами. Это позволило нам реализовать поле ввода произвольной формы с автозаполнением. Мы использовали движок Pars. Expression Grammar PEG.js, используя следующую грамматику:

logical_and ::= expression "AND" logical_and
expression  ::= "NOT" expression / primary
primary     ::= "(" logical_or ")
              | rules
rules       ::= node relation node
              | node relation "ANY(" node+ ")"
              | node relation "ALL(" node+ ")“
              | node.property "=" value
              | node.property "!=" value
              | node.property "IN ANY(“ value+ “)"

Эта грамматика позволяет пользователю выражать более сложные запросы, такие как:

Service IMPLEMENTS ANY('S3', 'SWIFT') AND (Service COMPLIES_WITH 'GDPR' OR Provider LOCATED_IN 'European Economic Area')

Service.type = 'object storage' AND Service LOCATED_IN ALL('France', 'Germany')

Наконец, исходный код выпускается под лицензией BSD-3, и мы раскрываем спецификации OpenAPI, JSONSchema и JSON-LD для облегчения взаимодействия и повторного использования.


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

DEALS 06/2020

• E5-1620v2 [4c-8t] (3.7GHz) / 32GB DDR3 ECC 1333MH / SoftRAID 2x 800 SSD — 4300р/мес и 1500р установка
• W-2145 [8c-16t] (4.5GHz) / 128 DDR4 ECC 2666MHz / 2x 960GB NVMe SoftRAID — 10700р/мес (можно докупать до 256 IP)

Писать тут
asuka.onl/billmgr

Так же добавлено облако ОВХ 2020, панель управления дается, firewall там все такое.