Жива ли Java на предприятии?
Ruby, Python, Swift, Go, Erlang, Rust, Decay, Corrosion, Decomposition… Я, конечно, шучу, но вы тоже не запутались? В наши дни так много модных языков программирования, что это почти стыдно за богатство. Это похоже на то, как если бы вас пригласили на пир, состоящий исключительно из тапас, сотни их, и вы не знаете, с чего начать. Как насчет Явы? В последние дни я мало что слышал о Java на технических сайтах, которые я слежу за новостями. Ява мертва? Или просто стало скучно?
Журнал IEEE Spectrum, типичное скучное издание для профессионалов с инженерным складом ума, таких как я, недавно оценил Java по популярности среди читателей Spectrum чуть ниже Python и C (прикиньте) и немного выше C# и C++. BetaNews также считает, что Java по-прежнему актуален и оценивает его как самый популярный язык программирования, хотя и предполагает, что C набирает силу. Тем не менее, если вы просмотрите доски таких сайтов, как Reddit и Quora, а также других социальных сетей, вы можете обнаружить почти каждый год громкие прогнозы о том, что «Java мертва, да здравствует X», где X — это новейший, самый популярный и модный новый язык программирования.. Это происходит особенно всякий раз, когда появляется новое откровение о какой-то огромной новой дыре в безопасности, обнаруженной в среде выполнения Java или каком-либо другом компоненте среды Java.
Однако правда в том, что это зависит от того, с кем вы разговариваете. Многие из моих коллег по ИТ работают на крупных предприятиях, либо в крупных корпорациях, либо в транснациональных корпорациях, таких как IBM. В таких местах Java кажется очень живым, поэтому я обратился к нескольким коллегам, чтобы узнать их мысли о том, что хорошо, что плохо, а что плохо в Java. Чтобы заставить нас задуматься над этой темой, вот три разных комментария, которые я получил от коллег.
Java: необходимое зло
Наш первый комментарий от Джеймса, который работает в области информационных технологий в университете:
«Java — неизбежное зло, так как ряд автономных и веб-приложений здесь, в университете, требуют этой платформы. В последнее время Oracle пытается снизить риски безопасности, и это здорово, но при этом создает новые проблемы для администраторов и конечных пользователей. Когда Google объявил об отказе от поддержки NPAPI в версии 45 Chrome, все стало еще хуже. Мы отправили запросы в службу поддержки, так как NPAPI отключен в текущей версии. Однако мне было бы интересно узнать, как другие корпоративные администраторы обрабатывают Java и другое стороннее программное обеспечение с высоким уровнем риска. Нам удалось удалить его на нескольких системах, но в целом наша стратегия заключалась в защите рабочих станций (брандмауэр/IPS, черные списки, EMET, объекты групповой политики, защита от вирусов) и обновлении Java с помощью набора инструментов для развертывания приложений через SCCM. Говоря об обновлении Java… Мне кажется, или Oracle намеренно усложняет поддержку Java на предприятии?»
Постоянная проблема
Другой коллега, у которого были опасения по поводу Java, — Джеффри. Он высказал следующие наблюдения:
«Один аспект управления Java, который не рассматривается, — это наличие нескольких частных Java JRE в одной системе. Хотя может существовать общесистемная установка Java для использования с браузерами и апплетами, каждое приложение, использующее Java (например, Open Office или Oracle Database Server), может установить свою собственную частную копию Java. В зависимости от версии установленного приложения (особенно устаревших приложений) может быть установлено несколько серий Java (например, Java 1.4.x, 1.5.x, 1.6.x), каждую из которых необходимо обновить. Хотя Oracle предоставляет бесплатную поддержку для Java 1.7 (7.x) и 1.8 (8.x), если поставщик больше не поддерживает приложение, для более старых версий требуется специальная подписка на Java (для сторонних приложений) или поддержка Oracle ( для приложений Oracle), чтобы получить текущие исправленные версии в этих сериях. Даже если администратору известен каждый экземпляр Java в системе ( вопрос), обновление Java (даже внутри серии) требует тестирования и может вызвать проблемы с функциональностью или производительностью. Возможно, вы помните, что несколько лет назад Oracle обнаружила ошибку с плавающей запятой в текущих на тот момент версиях Java. В ответ Oracle выпустила инструмент для определения всех версий, установленных в конкретной системе, и исправления уязвимых версий. Будем надеяться, что у администраторов есть инструменты для определения всех версий Java, установленных в системе в большинстве организаций, но в небольших организациях таких инструментов может не быть. В любом случае установка исправлений все еще может быть проблематичной, особенно для устаревших приложений и критически важных приложений, требующих расширенного тестирования новых версий Java перед их операционным развертыванием. И это не просто теоретическое соображение. Я поддерживал крупную организацию, в которой это было постоянной проблемой из-за нескольких серверов, на каждом из которых было установлено несколько приложений на основе Java (в частности, устаревшие приложения, некоторые из которых были Oracle, а некоторые — сторонние), и регулярные обновления Java, выпущенная Oracle».
Теперь это просто ФУД
В то время как некоторые из тех, кто работает в сфере ИТ, могут чувствовать, как Джеймс и Джеффри, что Java является либо необходимым злом, либо постоянной проблемой, с которой нужно иметь дело, другие, такие как системный менеджер Дейв, занимают другую позицию по этому вопросу:
«Относительно недавних вопросов о Java на предприятии, особенно в отношении проблем безопасности: в отрасли довольно много FUD и дезинформации о Java, даже среди магазинов Java, которые должны знать лучше. Я знаю, потому что я участвовал в переговорах Norex с другими магазинами Java, которые паниковали по поводу безопасности Java, которая даже не имела отношения к тому, как они использовали Java. Средства массовой информации кричат об «уязвимости» Java, не делая различий между подходами к развертыванию Java, и тогда все, кто хоть как-то связан с Java, впадают в панику. Точно так же, как некоторые люди до сих пор верят в связь между Java и JavaScript (вообще нет), некоторые считают, что Java — это монолитная среда выполнения, которая используется и развертывается только одним способом. Совсем не тот случай.
Отказ от апплетов и зависимость от подключаемого модуля Java для браузера устранят почти все основные уязвимости. Наша корпоративная разработка в основном ведется на Java вот уже более десяти лет, и мы избегали разработки апплетов, как чумы. Плагины для браузера создают гораздо большую «поверхность» для атаки, чем локальная клиентская или серверная установка среды выполнения Java. По сути, они пробивают брешь в вашем брандмауэре и позволяют мошенническому удаленному коду выполняться в вашем браузере — если песочница скомпрометирована из-за эксплойта, вы только что предоставили врагу доступ к вашей локальной среде и корпоративной сети.
Мы разработали и развернули десятки Java-приложений на нашем предприятии, но ни одно из них не запускается из браузера — это было сознательное решение, которое мы приняли с самого начала. К сожалению, у нас есть несколько приобретенных сторонних решений, которым требуется поддержка апплетов, и это было нашей единственной настоящей проблемой. Столкнувшись с обязательным обновлением Java для исправления дыры в безопасности (как в случае с Java 7 до обновления 51 пару лет назад), мы изо всех сил пытались найти безопасную, совместимую версию Java, с которой были бы совместимы все эти приложения, поскольку вы может иметь только одну активную «системную» JRE (которая также предоставляет плагин). Мы рассчитываем на то, что наши поставщики уменьшат или устранят требования к апплетам, и мне бы хотелось, чтобы Oracle прекратила поддержку апплетов и отказалась от их использования. Маловероятно, учитывая, что теперь они продвигают его как аргумент для продажи JavaFX, преемника Swing, который позволяет вам написать свой графический интерфейс один раз и работать как толстый клиент или веб-я опасаюсь, что магазины будут привлечены к этой «функции», не понимая ее последствий..
За пределами браузера, с надлежащей традиционной защитой клиента и сервера (брандмауэры, ACL и т. д.), среды выполнения Java исторически несли очень небольшой риск (почти все такие риски были связаны с внутренней атакой, а не с внешней). В отличие от подключаемого модуля для браузера, который принадлежит единственной «системной» JRE, вы можете развернуть несколько клиентских сред выполнения Java и указать каждому приложению свою собственную версию, если это необходимо, что сделает обновление Java менее проблематичным. Мы внедрили эту модель в наши корпоративные развертывания Java, где приложение связывает желаемую JRE и работает независимо от «системной» JRE или любой другой JRE на том же хосте».
Просто управляйте им правильно!
Наконец, есть такие коллеги, как Джереми Московиц, Microsoft MVP и основатель PolicyPak Software. Когда я спросил Джереми о проблемах с Java, он ответил следующее:
«Как MVP групповой политики, когда мне задали вопрос «Как мы должны управлять X на предприятии?» Я построил компанию вокруг этого. И с 2012 года мы работаем как настоящие гангстеры. Мы управляем сотнями приложений, таких как Java, Firefox, Flash и всем остальным, с чем практически невозможно справиться. Вот несколько видеороликов о том, как мы управляем Java. И у нас есть сотни тысяч мест под управлением, и мы делаем это таким образом».
Не забудьте также посетить веб-сайт Джереми, где он ведет блог и располагает некоторыми дополнительными ресурсами по групповой политике, а также предлагает интерактивное и онлайн-обучение.