На современном рынке IT есть сотни готовых решений для организации коммуникаций, хранения файлов и коллективной работы. Однако для некоторых компаний их использование может иметь больше минусов, чем плюсов. Об обратной стороне популярных платформ и об альтернативах им рассказывает Олег Пономарев, один из основателей Rubicom Tech.
Сегодня любая компания работает в глобальной сети Интернет и задействование публичных сервисов кажется логичным. Представители бизнеса используют проприетарные и публичные решения: корпоративную почту Gmail или других провайдеров, облачные хранилища и офисные онлайн-приложения от Microsoft, популярные мессенджеры и другие сервисы.
Несмотря на очевидные удобство, простоту и стабильность таких решений, растет число компаний, для которых такой путь наименьшего сопротивления может стать источником ограничений в работе, неоправданных расходов и несоответствия корпоративной политике по работе с данными.
Кому не подходят публичные IT-сервисы
Тем, кому нужны высокий уровень гибкости, совместимости со сторонними или собственными решениями, масштабирования при дальнейшем развитии проекта, тем, кому требуется реализация специфических фичей. Тем, кто не имеет права пользоваться определенными сервисами из-за требований закона. И тем, у кого строгая политика защиты данных.
Соответствие требованиям регуляторов
Действующий в России 152-ФЗ «О персональных данных» запрещает хранить личную информацию россиян в других странах. Если провайдер не гарантирует размещения мастер-базы данных наших сограждан на серверах в России, за использование его решения могут оштрафовать. Еще более жесткому регулированию подвергаются медицинские данные пациентов или сведения, составляющие государственную тайну.
Конфиденциальность данных
Та же электронная почта на бесплатном хостинге оказывается доступной нескольким лицам. Провайдер обычно зарабатывает на том, что анализирует ваши письма и предлагает рекламу, а потенциальному хакеру порой достаточно взломать почтовый ящик администратора домена на публичном сервисе, чтобы получить доступ к почтовым ящикам сотрудников. Между поставщиком бесплатных сервисов и бизнес-пользователями нет договора о возмещении, защите данных, а значит, никто не будет компенсировать потери и отвечать за подобный инцидент.
Более того, в пользовательском соглашении многих интернет-компаний прописаны такие пункты, по которым они оставляют за собой право передавать определенные данные маркетинговым партнерам, накапливать и анализировать их, а также передавать государственным службам.
Контроль за инфраструктурой
Учитывая, что за последний год в России количество фишинговых сайтов удвоилось, а количество успешных атак выросло в 10 раз, бесконтрольная инфраструктура создает дополнительные риски. Если при помощи социальной инженерии злоумышленнику удалось обмануть сотрудника и получить логин и пароль или подложить вредоносный файл, публичный хостинг уже не защитит данные. Ответственность за безопасность информации лежит в первую очередь на пользователях.
Гибкость и совместимость
Многие платформы предлагают сервисы для командной работы на основе подписок. При росте (особенно резком) числа активных пользователей, объема данных или дополнительных опций подписка может оказаться невыгодной.
Гарантии доступности сервиса
У каждого поставщика услуг свои правила, и по ним вам могут отказать в предоставлении сервиса. Решит почтовый сервис, что вы рассылаете спам или вирусы, и приостановит доступ к учетным записям. Все чаще американские открытые платформы отключают учетные записи по своему усмотрению. И тогда вы можете оказаться без контента, почтовых ящиков или файлов, записанных в облако. И ситуацию никак не исправить – провайдер бесплатного сервиса ничего вам не должен.
В конце июля YouTube заблокировал канал «Царьград» без всяких объяснений. А в апреле Google заблокировал аккаунт Федерального агентства новостей, ссылаясь на санкции.
On-рremise-системы: проприетарные решения или оpen source
Тем, кто не может использовать публичные сервисы, рекомендуем создавать или приобретать собственные ИТ-системы и решения, так называемые On-рremise-системы. Они могут по старинке размещаться на ваших физических серверах или в центрах обработки данных (ЦОД) провайдера, который гарантирует размещение серверов на нужной вам локации или сразу нескольких, обеспечивает надлежащий уровень их защиты от взломов и отвечает за безотказное обслуживание.
Развивать собственное решение можно на базе проприетарных технологий, принадлежащих компаниям, или с помощью систем с открытым исходным кодом.
Проприетарные решения больше подходят небольшим компаниям типа ИП с отсутствием IT-экспертизы. Им проще и безопаснее использовать готовые системы, за которые поставщик отвечает и которые может поддерживать. Гиганты рынка также часто используют проприетарные решения, так как для них вопрос стоимости лицензий или контрактов поддержки может отходить на второй план.
Другая часть компаний, которым требуется создать что-то свое, адаптировать работу платформы под специфические задачи, а также организации с повышенными требованиями к IT или к защите данных чаще выбирают решения оpen source. Открытый исходный код гарантирует возможность доработки любого ПО под задачи компании, а также отсутствие шпионских закладок. Кроме того, для решений open source расходы чаще связаны с оплатой времени специалистов для настройки и администрирования, а не с оплатой лицензий на ПО, что при разумном подходе может сэкономить компании не один миллион рублей.
К примеру, чтобы установить на iPhone специальные программы или фичи для своей корпорации, вам придется пройти 7 кругов ада, и будут они не техническими, а бюрократическими. Внедрить свое приложение в экосистему будет сложно, потому что Apple хочет, чтобы вы подключились к iCloud и пользовались готовыми стандартными сервисами.
Android, напротив, позволяет взять финальную версию операционной системы и модифицировать ее, вплоть до выпуска своей собственной версии. Можно в любое время доработать ПО, адаптировать к потребностям компании – допустим, запретить пользователю делать скриншоты в приложении. Не составит труда и установить сотрудникам приложение собственной разработки, даже не регистрируя его в Play Store.
В случае с закрытыми устройствами нельзя быть уверенным, что данные не утекают на сторону. Например, Apple обязаны передавать данные спецслужбам США. Поэтому в целях сохранности данных в России постоянно поднимают вопрос о запрете ПО MS Office и MS Windows в государственных учреждениях: никто не знает, какие сюрпризы могут оказаться в программном коде.
У проприетарного продукта могут быть не только ограниченные возможности, как в случае с числом пользователей или объемом хранилища в онлайн-сервисе. Разработчик имеет право отказать и в кастомизации. Так случилось с одним из наших клиентов, который закупил более 100 закрытых устройств, приобрел лицензии, но в процессе внедрения продукта в корпоративную среду получил отказ в модификации алгоритма работы единственного сетевого компонента. На все вопросы вендор отвечал, что лицензионное соглашение не подразумевает таких модификаций... и извинился за ошибку службы поддержки.
Решения open source, при условии их тщательной настройки, очень устойчивы к атакам. Большинство популярных у преступников методов направлены на популярные системы: публичные почтовые сервисы, ОС Windows, сетевые хранилища со стандартной конфигурацией. Злоумышленники стремятся заразить компьютеры пользователей ботнетами, украсть информацию, зашифровать данные, использовать почтовые ящики для рассылки спама и фишинга, установить кейлоггеры, организовать заказные атаки. И проприетарные системы в рядовых случаях оказываются более подвержены таким атакам.
Использование нестандартных решений, в частности переход с MS Windows на операционную систему из семейства Linux, позволяет автоматически защититься от вредоносных программ. А при грамотной политике системного администрирования степень защиты от атак, нацеленных на компанию, оказывается намного выше, чем со стандартными решениями.
Заключение
Наши системы защиты ежедневно пресекают сотни тысяч попыток подобрать пароль для доступа на сервер, «постучаться» на порт популярных приложений и т. п. Аналогичные атаки случаются каждую минуту на сети провайдеров почтовых услуг, сервисов совместной работы, облачные хранилища и серверы компаний любых размеров и отраслей. Одним словом, у всех, кто предоставляет доступ к своим сервисам через интернет.
Заказывая разработку или используя сервисы на базе решений оpen source, вы можете не беспокоиться о лимитах, контроле и внезапных изменениях параметров подписок. Вас не ограничат в масштабировании и возможностях кастомизации. Адаптируя открытый исходный код своими силами или вместе с IT-партнером, вы находитесь «на своей территории» и можете играть по своим правилам, создавая решения, необходимые именно вам. А в сочетании с размещением платформы в высокодоступном масштабируемом серверном пуле можно создать действительно выгодный, удобный и гибкий IT-плацдарм на годы вперед.
Узнать больше об облачных сервисах с фокусом на защиту данных можно на сайте Rubicom
Партнерский материал
В статье рассматриваются, в первую очередь, факторы, ограничивающие выбор публичных сервисов. В случае, если они начинают играть значимую роль при выборе ИТ-решения, то компании не остается ничего иного, как использовать on-premise-решения.
Выбор между on-premise-решениями (не важно: проприетарными или с открытым исходным кодом) уже выполняется на базе оценки их функциональных характеристик и экономической эффективности (как минимум, сравнительного анализа TCO).
И тут, мне кажется, не совсем корректно сравнивать между собой проприетарные технологии с системами с открытым исходным кодом.
Более важным считаю сравнивать варианты (стратегии) внедрения и последующего сопровождения выбранного информационного решения: берет ли компания на себя смелость осуществлять его доработку/кастомизацию либо ориентируется на максимальное использование стандартного функционала.
Было бы интересно узнать мнение автора по сравнению плюсов и минусов указанных стратегий.
Константин, спасибо за ваш вопрос. Меня зовут Олег и я давал интерью для материала выше.
Согласен, адекватная оценка TCO - это ключевое условие. И в этом плане сумма прямых и косвенных расходов может дать на выходе очень дорогостоящее решение на базе open source, а недешевые проприетарные продукты могут, в конечном счете, скэномить компании куда больше. Другое дело, что адекватно оценить TCO не получится без, действительно, профессиональной экпертизы с учетом возможно масштабирования.
Сравнение проводилось, прежде всего, в таком контексте: при планировании расходов на используемые продукты ПО с открытым исходным кодом дает больше свободы, потому что можно потратить деньги на фрилансера, имеющего необходимый опыт, а можно потратить неделю времени инженеров из собственной команды, купить что-то готовое или обойтись тем, что есть, пока не создано свое. Проприетарные продукты же будут в той или иной степени диктовать вам условия, распространяющиеся на железо, дополнительный фунционал, техническую поддержку. Таким образом, с одной стороны, расходы на приоретаемый софт становятся более предсказуемыми, а с другой стороны, возрастает степень зависимости бизнеса от эффективности конкретной команды разработчиков и полиики компании-вендора.
Сравнивая open source и пропритарные продукты, я ориентировался на прямую выгоду первого с точки зрения стоимости обслуживания каждого сотрудника или клиента, а также наличия возможности кастомизации, использования дополнительных модулей, интеграции с другими инструментами. Этот сегмент решений скорее всего "осядет" в компаниях, которые готовы тратить свое или оплачивать чужое время на разработку или доработку своей инфраструктуры или сервисов. На это, действительно, нужна смелость.
Максимальное использование базового функционала - подход, который более применим к коммерческим продуктам, ведь для них стандартный набор инструментов, готовых к использованию, шире. Можно быстро выпускать используемые продукты в production. Но в долгосрочной перспективе степень технической свободы или возможность масштабирования могут оказаться ограниченными, и придется подстраиваться под ПО, радикально менять платформу или приобретать лицензии уровня Enterprise. И последнее все равно может не решить все поставленные задачи. На уровне стандартного функционала и невысокого числа пользователей такой путь может оказаться оптимальным, особенно для компаний, по роду деятельности не связанных с IT. Но для проектов с высокой нагрузкой или для компаний с большой численностью сотрудников даже стандартный функционал популярных коммерчесских решений будет обходиться дорого.
Я бы сравнил это с легким и сложным путями и рассматривал в долгосрочной или краткосрочной перспективе с учетом целей бизнеса в конкретном случае.
Надеюсь, верно уловил вашу мысль)
Неплохая статья