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

Все описанное ниже касается белорусского Active Cloud. Я не знаю, отличаются ли услуги, предоставляемые в других регионах. Возможно, там что-то по-другому.

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

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

В панели биллинга много непонятной и лишней информации, в том числе, похоже, никому ненужных цифр. Примером может служить вкладка «Статистика и анализ». Это обратная сторона универсальности («коробочное» решение от Parallels). Есть и баги. Например, у меня не работает вкладка «Статистика трафика» — она просто не подгружается.

Кстати, интерфейс для общения с саппортом — отдельная тикетная система с базой знаний. Раньше она была топором врублена в биллинговую панель — было жутко неудобно. Похоже, разработчики это поняли и стали открывать ее в новом окне. Однако, она осталась неудобной. Слоновые заголовки, «потеря» страницы после F5 (это следствие отсутствия правильного URL в address bar), опять лишняя информация, причем частично на русском, частично на английском. Засоряют экран специальные уведомительные тикеты, которые плодятся вместе со счетами и виртуальными машинами. Здесь достаточно было бы уведомлений по e-mail.

Вторая панель — управление облаком от Cloud.com. Она тоже тяжелая и тормозящая, хотя и меньше биллинга. Не очень удобная навигация, многое приходится делать в два-три клика, когда можно было бы в один.

В обеих панелях не работает браузерная функция запоминания пароля (Firefox). В облачной панели мне сделали 2 учетки. Первая была на демо-доступ и сам логин был таким, как я просил. Вторую сделали на полный доступ, но логин без спроса сделали новый вида xxx1235465, где xxx — мой старый логин. Не очень удобно, особенно в купе с неработающим запоминанием пароля. Сменить второй логин не смогли. Кроме того, не смогли убрать и из самого биллинга завершенную подписку демо-доступа и некую ошибочно созданную подписку. Видимо, они будут мозолить мне глаза вечно.

При создании виртуальной машины ей задается группа (вписывается в текстовое поле). Все группы видны в меню. Машину можно удалить, но при этом группа не удалится. И переименовать группу нельзя. Раздражает.

Консоль виртуальной машины вроде работает без Java. Но она сделана на картинках-слайсах. Т.е. при изменении изображения на виртуальном экране виртуальной машины (консоль или GUI) подгружается новые картинки-квадратики. Из-за этого консоль работает медленно и с большой задержкой. Пользоваться ей неудобно.

У Active.by классный сайт. У них в штате классный дизайнер. Но их панели — это полная противоположность их сайту. И дизайнер там почти не бывал.

Кроме того, в панелях были конкретные баги. Пару раз писал в саппорт, обещали поправить. Поправили или нет — не проверял.

Само облако поначалу сбоило. Лично мне несколько раз саппорт решал проблемы отвалившейся на моей ВМ сети. При мне сеть во всем облаке (толи целиком, толи в его куске) полностью падала на несколько часов. После этого столкнулся с тем, что свежеустановленная из образа Debian x64 не получала IP по DHCP на первом и всех последующих запусках (повторялось каждый раз). После обращения в саппорт проблема была решена за пару дней. Я был в шоке…

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

Изначально мы хотели перевести в облако свои серверы. Но сделать это не смогли. Основной причиной тому были непонятные проблемы с производительностью дисковой подсистемы. Хотя синтетические измерения вроде бы и выдавали нормальные скорости I/O, но фактическая производительность рабочего сервера на Windows у нас оказалась колоссально хуже, чем на аналогичном по конфигурации голом железе.

Возможно, проблемы были на большом количестве IOPS (частое чтение мелких блоков). Мы не выяснили это до конца. Но факт есть факт: то, что у нас нормально работает на физическом выделенном сервере, перенести в облако мы не смогли — сильно педалит. Причем, четко видно, что педалит не по CPU, и не по памяти. Педалит именно по дисковому I/O.

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

Мне нравится Active.by. Я желаю им успехов в развитии. И надеюсь, что мой пост поможет им раскрыть глаза на собственные недостатки и исправить их. Удачи им в этом!

Актуальность информации — апрель 2012 года.

Полностью защитить протокол общения пользователя с сервером можно только одним способом — шифрование трафика. Экзотические способы шифрования, а также создание различного вида тоннелей мы не рассматриваем. Только обычное SSL-шифрование протокола HTTP, которое поддерживает любой современный браузер — HTTPS.

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

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

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

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

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

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

Именно так поступили в Яндексе. У них я подсмотрел способ определения доступности HTTPS. Подгружается JS с https://, который устанавливает флаг в DOM-модели страницы. Форма авторизации ведет себя по разному в зависимости от этого флага.

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

А как делают другие?

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

Mail.ru ведет себя как Яндекс, только их способа определения поддержки HTTPS я не нашел (хотя и не глубоко искал).

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

Facebook, как и Google, прекрассно работает по HTTPS. Авторизация по умолчанию защищенная. Пароль в открытом виде.

Вконтакте, Одноклассники, TUT.BY и Onliner.by по HTTPS не отвечают, защищенную авторизацию не предлагают, пароль идет в открытом виде.

oz.by по HTTPS предлагает принять самоподписанный сертификат, чтобы потом произвести редирект на HTTP. Пароль в открытом виде.

Вот такая статистика. Западные ресурсы и пользователи давно освоили основы безопасности в сети. Ведущие российские ресурсы защищают хотябы авторизацию пользователя. Ведущие белорусские ресурсы безопасность пользователей игнорируют полностью.

Долгое время белорусская версия была доступна по адресу google.com.by из-за того, что домен google.by был занят. Если точнее, то он был выкуплен Денисом Кораблевым из компании activemedia.by (я так и не понял, какую должность он там занимает — руководитель компании?). В это время на сайте крутился поисковый интерфейс Гугла, который вел на сам google.com, продавалась контекстная реклама и ссылки с главной страницы. Правда в сентябре 2008 сайт закрылся.

Вчера новостному проекту electroname.com и сайту netnews.by представитель Гугла Дмитрий Шоломко прокомментировал ситуацию и сообщил, что еще в декабре домен google.by отсужен у activemedia.by в Верховном Суде Республики Беларусь. Так же он сообщил: «Сейчас ведутся подготовительные работы к запуску сервисов Google на этом домене, и через некоторое время он будет функционировать в обычном режиме сайта Google». Эту информацию electroname.com также подтвердила Алла Забровская, директор по связям с общественностью Google Russia.

Кстати, мне не известны случаи до этого, когда домен в зоне .by был кем-то у кого-то отсужен. Не известны даже случаи подачи таких исков. Так что, вероятно, ситуацию с google.by можно считать хорошим прецедентом в BY-нете. Правда есть одно «но». По словам Дмитрия Шоломко, они обратились в суд с иском о нарушении прав на товарный знак и фирменное наименование, т.к. google.by в свое время копировал сайт google.com. Т.е. объектом иска выступал все же не сам домен непосредственно, а факт копирования интерфейса.

Жаль только, что этот процесс достойно не освещался в СМИ, так, как это происходит на западе и даже в России. Все прошло очень тихо.