В ответ на растущую потребность в поддержке растущих нагрузок в облаке, которые компании испытывают в этой новой среде, мы снижаем плату за установку на некоторых наших голых серверах. Не пропустите эти предложения, так как они исчезнут завтра!
us.ovhcloud.com/deals


НОВЫЕ ВИРТУАЛЬНЫЕ ЧАСТНЫЕ СЕРВЕРЫ
Мы рады объявить о запуске нашей новой линейки виртуальных частных серверов (VPS). С пятью различными предложениями новый ассортимент предлагает широкий выбор ценных вариантов по очень низкой цене.
Теперь стало проще, чем когда-либо, управлять частным сервером, устанавливать собственную ОС и развертывать выбранные приложения. Если вы новичок в облаке или планируете перейти от решения общего хостинга, наш VPS — это решение, которое вы ищете.
us.ovhcloud.com/vps/


КАЛИФОРНИЯ АССОЦИАЦИЯ РИЭЛТОРОВ Тематическое исследование
С OVHcloud в качестве партнера CALIFORNIA ASSOCIATION OF REALTORS (C.A.R.) перенесли свои локальные рабочие нагрузки в наши центры обработки данных без риска потери членства, идентификации или финансовых данных или нарушения работы их веб-сайта или приложений.
Автоматизация OVHcloud оказалась неоценимой в разрешении C.A.R. динамически расширять свою среду по мере необходимости. Посмотрите этот пример, чтобы узнать больше.
us.ovhcloud.com/resources/case-studies/california-association-realtors-car-makes-smart-move

Наш партнёр — РБК Pro — приглашает вас на бесплатный вебинар «Клиенты из интернета: как SEO‑продвижение может помочь бизнесу в 2020‑м».

Спикер – Артур Латыпов, генеральный директор рекламного агентства «SEO Интеллект». В SEO с 2005 года, принимал участие в продвижении более 350 проектов.

Вебинар состоится 15 июня в 19:00 по московскому времени.
Вы узнаете:

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

pro.rbc.ru/webinar/5e95cb269a79474d78d040fb

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

А еще мы знаем, как избавиться от этих трудностей, и хотим поделиться решением с вами. Приглашаем вас на бесплатный вебинар, где расскажем, как с помощью управляемых баз данных в облаке забыть о долгой настройке БД и сфокусировать силы команды на разработке продукта. Вы узнаете, как создавать масштабируемые кластеры баз данных в несколько кликов, планировать бюджет на БД и сокращать расходы на развертывание инфраструктуры.
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 не знает, кто такой Джон Админ, и не нуждается в этом: мы отделили часть аутентификации и авторизации. Только бастион должен знать и аутентифицировать администратора, а удаленный сервер только знает и доверяет бастиону (или, точнее, команде Джона Админа на бастионе). Это открывает целый ряд возможностей… но об этом подробнее в следующем посте!

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