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

Подозреваю речь идет об аналогии продукта типа Cisco ISE или Huawei Agile Controller, но межсетевой экран этими функциями не обладает (да и не должен). На текущий момент VLANs статично прописаны на портах (благо у Заказчика была информация по портам и пользователям). Цели проекта в нашем случае были жестко регламентированы Заказчиком – сегментировать сеть (разнести пользователей по группам) на имеющемся оборудовании (у них нет ни ISE, ни Agile Controller) и обеспечить максимальный контроль трафика между сегментами сети в сжатые сроки (ограничиваясь фильтрацией на уровне IP-адресов).

Нет. Не совсем понял откуда такой вывод. Было получено штатное расписание от отдела кадров и совместно с безопасниками были определены сети для каждой группы в штатном расписании (до этого был один большой сегмент под названием «пользователи»), на коммутаторах были созданы VLANs, на PaloAlto были созданы сети и привязаны к этим VLANs. Далее правила создавались по этим новым сетям.

Напомню, что изначально проект направлен на сегментацию сети, то есть людей разнесли по сетям в соответствии с их ролями.
Далее правила, да, были настроены по подсетям (уже новым) – это было требование заказчика для оперативного внедрения МСЭ в сеть. В ходе работ мы также внедрили сервер PaloAlto User Agent и интегрировали PaloAlto с AD. После этого мы выдали рекомендации заказчику в будущем перейти от системы правил по подсетям к системе правил по пользователям и группам пользователей, для этого мы провели демонстрацию как это делать.

За месяц после ввода в эксплуатацию – 2 обращения, но оба были по поводу трафика, который не должен иметь место по соображениям безопасности, поэтому решением было не включать их трафик (samba)

Да, узкоспециализированный

Вы имеете ввиду оптимизаторы bluecoat и citrix? Или citrix VDI? Это совсем другие решения. Идея вынести из филиалов/отделений данные приложений в ЦОД, а вычислительные мощности приложений оставить на периферии реализована только Riverbed-ом. Прямых аналогов этому решению нет.

Прямых налогов нет. Это действительно уникальное решение. Недавно Riverbed обновили линейку подобных устройств. Теперь самая маленькая железка этого класса SFED-2100. Вы можете посмотреть её характеристики на картинке в посте. Чтобы подобрать подходящую железку недостаточно просто кол-ва пользователей. Нужны подробности: кол-во серверов которые требуется на ней запустить, требования по железу у каждой VM, количество данных которые ежедневно записываются на диски/СХД пользователями филиала, полоса пропускания канала связи, требования к IOPS, количество соединений которые нужно оптимизировать, полоса пропускания канала связи и тд.

Если Приватбанк полностью отказался от файловых шар, централизовал Exchange, переложил все бизнес приложения на WEB — это замечательно! Однако стоит сравнить размеры Украины и России, как станет понятно, что в России это будет практически невозможно. Задержки протяженных каналов связи настолько замедлят работу, что встанет вопрос о целесообразности данной миграции. Хотя с другой стороны обычные оптимизаторы трафика Riverbed отлично справляются с задачей ускорения HTTP на каналах с большими задержками (в том числе спутниковых). В общем вычислитель должен быть в LAN-сети, иначе LAN-скорости попросту не получить.

С точки зрения калькулятора, есть два варианта –
1. В случае, если это приложение работает посредством «толстого» клиента, то эффекта от оптимизации будет мало. Т.к. будут выполняться короткие запросы-ответы, могу даже сделать сравнение такого приложения с работой telnet.
2. Если представить, что это приложение работает на базе http (как большинство современных приложений), то эффект будет значительный.
Во-первых за счет оптимизации http, который сжимается и оптимизируется очень хорошо – т.к. нужно как минимум загрузить web форму (того же калькулятора) в браузер клиента.
Во-вторых, если представить, что в виде ответа от сервера на заполненные поля в web форме мы получаем некий объемный отчет, который как правило избыточный, то эффект от использования оптимизатора за счет де-дупликации будет так же значительный.

Для каждого конкретного протокола прикладного уровня (из списка ускоряемых на L7) оптимизатор применяет свой специфический алгоритм оптимизации. Если мы говорим об SMTP, то здесь основной задачей является “вскрыть” шифрование. SMTP соединение устанавливается до SSL-соединения, таким образом, возникают сложности в определении момент запуска SSL-оптимизации. На помощь приходит L7 блейд оптимизатора, отвечающий за SMTP. Более того использование L7 блейда обеспечивает, что не нужно делать TLS-handshake для отправки каждого письма.
За нашу практику не встречали ситуаций когда из-за оптимизатора пользователь мог скачать удаленный файл или посмотреть удаленное письмо:)

На задержках 700ms RDP тормозит… Шанс есть, все зависит от устойчивости Вашей нервной системы или правильных успокаивающих средств Шучу! Не все так плохо.
Здесь многое будут зависеть от наличия потерь и доступной полосы пропускания.
В случае с RDP оптимизатор может побороть тормоза связанные с потерями и полосой пропускания (за счет сжатия и прозрачного проксирования TCP), но не задержками.

В оптимизатор встроены декодеры. Словарь оптимизатора заполняется оригинальными данными после декодирования. Это не совсем кеширование (точнее совсем не кеширование). Это дедупликация данных за счет замены уже записанных паттернов оригинальных данных ссылками. Эффективность высокая. Конкретные цифры зависят от количества избыточности в передаваемых данных. Опыт показывает, что эта избыточность есть всегда.

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

2. Дело в том, что оптимизатор не кеширует файлы целиком в прямом понимании этого слова. Оптимизатор хранит самые часто используемые сегменты данных в словаре (механизм SDR – Scalable Data Reference) и нет привязки к протоколу, по которому будет получен файл в филиале. Например, файл презентации PowerPoint передали по почте в филиал. А затем в случае загрузки этого же файла по FTP, но с небольшими изменениями, будет переданы только изменения, остальные данные будет переданы в виде коротких ссылок на сегменты данных. Т.е. весь файл передаваться полностью не будет. В случае, если файл >10 Мбайт и канал связи спутниковый, то это значительно экономит полосу пропускания.

Реальная задержка на каналах связи = 600 — 700 мс RTT. И в зависимости от внешних факторов может ухудшаться.
Если канал связи не загружен, то мы не увидим заметного ускорения работы RDP. Но с другой стороны, если канал связи сильно загружен, то оптимизаторы позволяют разгрузить канал связи, приоритезировать приложения и за счет этого повысить стабильность и ускорить RDP. В нашем случае мы добились заметного улучшение работы RDP.

В первую очередь SSL в отчете — это OWA.
Riverbed оптимизирует SMB с помощью нескольких техник:
— дедупликация (сжатие)
— ускорения на транспортном уровне TCP (спутниковый режим SCPS)
— ускорение на уровне приложений
Подобным образом выполняется оптимизация и других самых распространенных типов приложений.

Да, запись появится буквально через пару дней на странице вебинара на сайте.

«99% эффективности этих устройств в базе сигнатур, которая, неожиданно, скачивается из Америки чуть ли не ежечасно.» — это преувеличение. Сигнатуры – важная, но не единственная составляющая борьбы с DDoS-атаками. Очень много атак отбивается без сигнатур, с применением стандартных противомер. Недаром в статье упоминается, что «то же самое коллеги говорят и о сигнатурах – насколько велика не была бы сеть сенсоров и сколько бы трафика в ней не анализировалось, полагаться только на сигнатуры нельзя».
Да, ATLAS создан и поддерживается американской компанией, однако содержит информацию о тенденциях и событиях в глобальной сети и фактически является уникальной базой данных и знаний. Использовать ли эти знания, каждый решает сам. Кроме того, начиная с версии ПО Pravail 5.6 автоматическое скачивание может быть отключено. Сигнатуры ATLAS могут быть загружены и установлены администратором системы вручную.

Сравнивать оборудование с сервисом не стоит. Одно другое не исключает, а дополняет. Именно поэтому в статье говорится о многоуровневой защите.
Локальное оборудование ставят когда хотят:
а) минимизировать простои и время задержки на активацию/переключение услуги;
б) работы с SSL без отдачи приватных ключей сторонней организации;
в) полного контроля над ходом очистки от атак до ширины канала без необходимости привлечения сторонней организации.

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

В базовом варианте в сеть заказчика нужно установить следующие компоненты:
1. Сенсор для съема и хранения копии пакетов — Shark Sensor. Устанавливается около серверов в ЦОДе.
2. Коллектор NetFlow статистики — Gateway.
3. Головное устройство консолидации статистики, построения отчетов и аналитики — Cascade Profiler. Место установки не имеет значение, главное IP connectivity до Shark Sensor и Gateway.

Если нужно анализировать сетевые потоки внутри регионального офиса, то устанавливаем дополнительный Shark Sensor там.

Главное преимущество WAAS в интеграции с продуктами Cisco. Понимаю вашу точку зрения — с учётом, что у вас написано в профиле про Cisco — но все же давайте обратимся к фактам. Факты таковы, что в сегменте WOC (Wan Optimization Controllers) Riverbed уже три года подряд занимает более 50% рынка. В 2013 году Riverbed остался единственным лидером сегмента по Gartner. Gartner не делает такие смелые заключения просто так. Это всегда очень серьезные исследования, которым очень и очень доверяют на рынке. Учитывая, то что Riverbed — нишевой игрок, и его возможности ограничены по сравнению с более крупными производителями, то получить больше половины рынка они смогли только за счет большей эффективности оптимизации и более широкого функционала, чем у конкурентов. Проще говоря, их решение банально лучше для большинства покупателей. По практике в России отмечу, что Riverbed очень и очень хорошо себя показал. Я не предлагаю ставить только его — мы интегрируем и решения Cisco, и других вендоров — но при полном расчёте кейса ситуация в РФ не отличается от мировой, описанной Gartner.