Безопасность и виртуальная Java-машина. Введение в программирование на Java
Итак, Java обладает длинной и непростой историей развития, однако настало время рассмотреть, что же получилось у создателей, какими свойствами обладает данная технология.
Самое широко известное, и в то же время вызывающее самые бурные споры, свойство - много- или кроссплатформенность . Уже говорилось, что оно достигается за счет использования виртуальной машины JVM , которая является обычной программой, исполняемой операционной системой и предоставляющей Java -приложениям все необходимые возможности. Поскольку все параметры JVM специфицированы, то остается единственная задача - реализовать виртуальные машины на всех существующих и используемых платформах.
Наличие виртуальной машины определяет многие свойства Java , однако сейчас остановимся на следующем вопросе - является Java языком компилируемым или интерпретируемым? На самом деле, используются оба подхода.
Исходный код любой программы на языке Java представляется обычными текстовыми файлами, которые могут быть созданы в любом текстовом редакторе или специализированном средстве разработки и имеют расширение.java. Эти файлы подаются на вход Java -компилятора, который транслирует их в специальный Java байт-код . Именно этот компактный и эффективный набор инструкций поддерживается JVM и является неотъемлемой частью платформы Java .
Результат работы компилятора сохраняется в бинарных файлах с расширением.class. Java -приложение, состоящее из таких файлов, подается на вход виртуальной машине, которая начинает их исполнять, или интерпретировать, так как сама является программой.
Многие разработчики поначалу жестко критиковали смелый лозунг Sun "Write once, run everywhere", обнаруживая все больше и больше несоответствий и нестыковок на различных платформах. Однако надо признать, что они просто были слишком нетерпеливы. Java только появилась на свет, а первые версии спецификаций были недостаточно исчерпывающими.
Очень скоро специалисты Sun пришли к выводу, что просто свободно публиковать спецификации (что уже делалось задолго до Java ) недостаточно. Необходимо еще и создавать специальные процедуры проверки новых продуктов на соответствие стандартам. Первый такой тест для JVM содержал всего около 600 проверок, через год их число выросло до десяти тысяч и с тех пор все время увеличивается (именно его в свое время не смог пройти MS IE 4.0). Безусловно, авторы виртуальных машин все время совершенствовали их, устраняя ошибки и оптимизируя работу. Все-таки любая, даже очень хорошо задуманная технология требует времени для создания высококачественной реализации. Аналогичный путь развития сейчас проходит Java 2 Micro Edition (J2ME ), но об этом позже.
Следующим по важности свойством является объектная ориентированность Java , что всегда упоминается во всех статьях и пресс-релизах. Сам объектно-ориентированный подход (ООП) рассматривается в следующей лекции, однако важно подчеркнуть, что в Java практически все реализовано в виде объектов - потоки выполнения (threads) и потоки данных (streams), работа с сетью, работа с изображениями, с пользовательским интерфейсом , обработка ошибок и т.д. В конце концов, любое приложение на Java - это набор классов, описывающих новые типы объектов.
Подробное рассмотрение объектной модели Java проводится на протяжении всего курса, однако обозначим основные особенности. Прежде всего, создатели отказались от множественного наследования. Было решено, что оно слишком усложняет и запутывает программы. В языке используется альтернативный подход - специальный тип " интерфейс ". Он подробно рассматривается в соответствующей лекции.
Далее, в Java применяется строгая типизация . Это означает, что любая переменная и любое выражение имеет тип, известный уже на момент компиляции. Такой подход применен для упрощения выявления проблем, ведь компилятор сразу сообщает об ошибках и указывает их расположение в коде. Поиск же исключительных ситуаций (exceptions - так в Java называются некорректные ситуации) во время исполнения программы (runtime) потребует сложного тестирования, при этом причина дефекта может обнаружиться совсем в другом классе. Таким образом, нужно прикладывать дополнительные усилия при написании кода, зато существенно повышается его надежность (а это одна из основополагающих целей, для которых и создавался новый язык).
В Java существует всего 8 типов данных, которые не являются объектами. Они были определены с самой первой версии и никогда не менялись. Это пять целочисленных типов: byte, short, int, long, а также к ним относят символьный char. Затем два дробных типа float и double и, наконец, булевский тип boolean. Такие типы называются простыми, или примитивными (от английского primitive ), и они подробно рассматриваются в лекции, посвященной типам данных. Все остальные типы - объектные или ссылочные (англ. reference ).
Синтаксис Java почему-то многих ввел в заблуждение. Он действительно создан на основе синтаксиса языков C/C++, так что если посмотреть на исходный код программ, написанных на этих языках и на Java, то не сразу удается понять, какая из них на каком языке написана. Это почему-то дало многим повод думать, что Java - это упрощенный C++ с дополнительными возможностями, такими как garbage collector . Автоматический сборщик мусора (garbage collector ) мы рассмотрим чуть ниже, но считать, что Java такой же язык, как и C++,- большое заблуждение.
Конечно, разрабатывая новую технологию, авторы Java опирались на широко распространенный язык программирования по целому ряду причин. Во-первых, они сами на тот момент считали C++ своим основным инструментом. Во-вторых, зачем придумывать что-то новое, когда есть вполне подходящее старое? Наконец, очевидно, что незнакомый синтаксис отпугнет разработчиков и существенно осложнит внедрение нового языка, а ведь Java должна была максимально быстро получить широкое распространение. Поэтому синтаксис был лишь слегка упрощен, чтобы избежать слишком запутанных конструкций.
Но, как уже говорилось, С++ принципиально не годился для новых задач, которые поставили себе разработчики из компании Sun, поэтому модель Java была построена заново, причем в соответствии с совсем другими целями. Дальнейшие лекции будут постепенно раскрывать конкретные различия.
Что же касается объектной модели, то она скорее была построена по образцу таких языков, как Smalltalk от IBM, или разработанный еще в 60-е годы в Норвежском Вычислительном Центре язык Simula, на который ссылается сам создатель Java Джеймс Гослинг.
Другое немаловажное свойство Java - легкость в освоении и разработке - также получило неоднозначную оценку. Действительно, авторы потрудились избавить программистов от наиболее распространенных ошибок, которые порой допускают даже опытные разработчики на C/C++. И первое место здесь занимает работа с памятью.
В Java с самого начала был введен механизм автоматической сборки мусора (от английского garbage collector ). Предположим, программа создает некоторый объект, работает с ним, а дальше наступает момент, когда он больше уже не нужен. Необходимо освободить занимаемую память, чтобы не мешать операционной системе нормально функционировать. В С/С++ это необходимо делать явным образом из программы. Очевидно, что при таком подходе существует две опасности - либо удалить объект, который еще кому-то необходим (и если к нему действительно произойдет обращение, то возникнет ошибка), либо не удалять объект, ставший ненужным, а это означает утечку памяти, то есть программа начинает потреблять все большее количество оперативной памяти.
При разработке на Java программист вообще не думает об освобождении памяти. Виртуальная машина сама подсчитывает количество ссылок на каждый объект, и если оно становится равным нулю, то такой объект помечается для обработки garbage collector . Таким образом, программист должен следить лишь за тем, чтобы не оставалось ссылок на ненужные объекты. Сборщик мусора - это фоновый поток исполнения, который регулярно просматривает существующие объекты и удаляет уже не нужные. Из программы никак нельзя повлиять на работу garbage collector , можно только явно инициировать его очередной проход с помощью стандартной функции. Ясно, что это существенно упрощает разработку программ, особенно для начинающих программистов.
Однако опытные разработчики были недовольны тем, что они не могут полностью контролировать все, что происходит с их системой. Нет точной информации, когда именно будет удален объект, ставший ненужным, когда начнет работать (а значит, и занимать системные ресурсы) поток сборщика мусора и т.д. Но, при всем уважении к опыту таких программистов, необходимо отметить, что подавляющее количество сбоев программ, написанных на С/С++, приходится именно на некорректную работу с памятью, причем порой это случается даже с широко распространенными продуктами весьма серьезных компаний.
Кроме того, особый упор делался на легкость освоения новой технологии. Как уже было сказано, ожидалось (и эти ожидания оправдались, в подтверждение правильности выбранного пути!), что Java должна получить максимально широкое применение, даже в тех компаниях, где никогда до этого не занимались программированием на таком уровне (бытовая техника типа тостеров и кофеварок, создание игр и других приложений для сотовых телефонов и т.д.). Был и целый ряд других соображений. Продукты для обычных пользователей, а не профессиональных программистов, должны быть особенно надежными. Internet стал Всемирной Сетью, поскольку появились непрофессиональные пользователи, а возможность создавать апплеты для них не менее привлекательна. Им требовался простой инструмент для создания надежных приложений.
Наконец, Internet-бум 90-х годов набирал обороты и выдвигал новые, более жесткие требования к срокам разработки. Многолетние проекты, которые были в прошлом обычным делом, перестали отвечать потребностям заказчиков, новые системы надо было создавать максимум за год, а то и за считаные месяцы.
Кроме введения garbage collector , были предприняты и другие шаги для облегчения разработки. Некоторые из них уже упоминались - отказ от множественного наследования, упрощение синтаксиса и др. Возможность создания многопоточных приложений была реализована в первой же версии Java (исследования показали, что это очень удобно для пользователей, а существующие стандарты опираются на телетайпные системы, которые устарели много лет назад). Другие особенности будут рассмотрены в следующих лекциях. Однако то, что создание и поддержка систем действительно проще на Java , чем на C/C++, давно является общепризнанным фактом. Впрочем, все-таки эти языки созданы для разных целей, и каждый имеет свои неоспоримые преимущества.
Следующее важное свойство Java - безопасность . Изначальная нацеленность на распределенные приложения, и в особенности решение исполнять апплеты на клиентской машине, сделали вопрос защиты одним из самых приоритетных. При работе любой виртуальной машины Java действует целый комплекс мер. Далее приводится лишь краткое описание некоторых из них.
Во-первых, это правила работы с памятью. Уже говорилось, что очистка памяти производится автоматически. Резервирование ее также определяется JVM , а не компилятором, или явным образом из программы, разработчик может лишь указать, что он хочет создать еще один новый объект. Указатели по физическим адресам отсутствуют принципиально.
Во-вторых, наличие виртуальной машины-интерпретатора значительно облегчает отсечение опасного кода на каждом этапе работы. Сначала байт-код загружается в систему, как правило, в виде class-файлов. JVM тщательно проверяет, все ли они подчиняются общим правилам безопасности Java и не созданы ли злоумышленниками с помощью каких-то других средств (и не искажены ли при передаче). Затем, во время исполнения программы, интерпретатор легко может проверить каждое действие на допустимость. Возможности классов, которые были загружены с локального диска или по сети, существенно различаются (пользователь легко может назначать или отменять конкретные права). Например, апплеты по умолчанию никогда не получат доступ к локальной файловой системе. Такие встроенные ограничения есть во всех стандартных библиотеках Java .
Наконец, существует механизм подписания апплетов и других приложений, загружаемых по сети. Специальный сертификат гарантирует, что пользователь получил код именно в том виде, в каком его выпустил производитель. Это, конечно, не дает дополнительных средств защиты, но позволяет клиенту либо отказаться от работы с приложениями ненадежных производителей, либо сразу увидеть, что в программу внесены неавторизованные изменения. В худшем случае он знает, кто ответственен за причиненный ущерб.
Совокупность описанных свойств Java позволяет утверждать, что язык весьма приспособлен для разработки Internet- и интранет (внутренние сети корпораций)-приложений.
Наконец, важная отличительная особенность Java - это его динамичность . Язык очень удачно задуман, в его развитии участвуют сотни тысяч разработчиков и многие крупные компании. Основные этапы этого развития кратко освещены в следующем разделе.
Итак, подведем итоги. Java -платформа обладает следующими преимуществами:
- переносимость, или кроссплатформенность ;
- объектная ориентированность, создана эффективная объектная модель;
- привычный синтаксис С/С++;
- встроенная и прозрачная модель безопасности ;
- ориентация на Internet-задачи, сетевые распределенные приложения;
- динамичность , легкость развития и добавления новых возможностей;
- простота освоения.
Но не следует считать, что более легкое освоение означает, что изучать язык не нужно вовсе. Чтобы писать действительно хорошие программы, создавать большие сложные системы, необходимо четкое понимание всех базовых концепций Java и используемых библиотек. Именно этому и посвящен данный курс.
Основные версии и продукты Java
Сразу оговоримся, что под продуктами здесь понимаются программные решения от компании Sun, являющиеся "образцами реализации" ( reference implementation ).
Итак, впервые Java была объявлена 23 мая 1995 года. Основными продуктами, доступными на тот момент в виде бета-версий, были:
- Java language specification , JLS , спецификация языка Java (описывающая лексику, типы данных, основные конструкции и т.д.);
- спецификация JVM ;
- Java Development Kit , JDK - средство разработчика, состоящее в основном из утилит, стандартных библиотек классов и демонстрационных примеров.
Спецификация языка была составлена настолько удачно, что практически без изменений используется и по сей день. Конечно, было внесено большое количество уточнений, более подробных описаний, были добавлены и некоторые новые возможности (например, объявление внутренних классов), однако основные концепции остаются неизменными. Данный курс в большой степени опирается именно на спецификацию языка.
Спецификация JVM предназначена в первую очередь для создателей виртуальных машин, а потому практически не используется Java -программистами.
JDK долгое время было базовым средством разработки приложений. Оно не содержит никаких текстовых редакторов, а оперирует только уже существующими Java -файлами. Компилятор представлен утилитой javac (java compiler). Виртуальная машина реализована программой java . Для тестовых запусков апплетов существует специальная утилита appletviewer . Наконец, для автоматической генерации документации на основе исходного кода прилагается средство javadoc .
Первая версия содержала всего 8 стандартных библиотек:
- java.lang - базовые классы, необходимые для работы любого приложения (название - сокращение от language);
- java.util - многие полезные вспомогательные классы;
- java.applet - классы для создания апплетов ;
- java.awt , java.awt.peer - библиотека для создания графического интерфейса пользователя (GUI ), называется Abstract Window Toolkit , AWT , подробно описывается в лекции 11;
- java.awt.image - дополнительные классы для работы с изображениями;
- java.io - работа с потоками данных (streams) и с файлами;
- java.net - работа с сетью.
Таким образом, все библиотеки начинаются с java , именно они являются стандартными. Все остальные (начинающиеся с com, org и др.) могут меняться в любой версии без поддержки совместимости.
Финальная версия JDK 1.0 была выпущена в январе 1996 года.
Сразу поясним систему именования версий. Обозначение версии состоит из трех цифр. Первой пока всегда стоит 1. Это означает, что поддерживается полная совместимость между всеми версиями 1.х.х. То есть программа, написанная на более старом JDK , всегда успешно выполнится на более новом. По возможности соблюдается и обратная совместимость - если программа откомпилирована более новым JDK , а никакие новые библиотеки не использовались, то в большинстве случаев старые виртуальные машины смогут выполнить такой код.
Вторая цифра изменилась от 0 до 4 (последняя на момент создания курса). В каждой версии происходило существенное расширение стандартных библиотек (212, 504, 1781, 2130 и 2738 - количество классов и интерфейсов с 1.0 по 1.4), а также добавлялись некоторые новые возможности в сам язык. Менялись и утилиты, входящие в JDK .
Наконец, третья цифра означает развитие одной версии. В языке или библиотеках ничего не меняется, лишь устраняются ошибки, производится оптимизация, могут меняться (добавляться) аргументы утилит. Так, последняя версия JDK 1.0 - 1.0.2.
Хотя с развитием версии 1.х ничего не удаляется, конечно, какие-то функции или классы устаревают. Они объявляются deprecated , и хотя они будут поддерживаться до объявления 2.0 (а про нее пока ничего не было слышно), пользоваться ими не рекомендуется.
Вместе с первым успехом JDK 1.0 подоспела и критика. Основные недостатки, обнаруженные разработчиками, были следующими. Во-первых, конечно, производительность. Первая виртуальная машина работала очень медленно. Это связано с тем, что JVM , по сути, представляет собой интерпретатор, который работает всегда медленнее, чем исполняется откомпилированный код. Однако успешная оптимизация, устранившая этот недостаток, была еще впереди. Также отмечались довольно бедные возможности AWT , отсутствие работы с базами данных и другие.
В декабре 1996 года объявляется новая версия JDK 1.1, сразу выкладывается для свободного доступа бета-версия. В феврале 1997 года выходит финальная версия. Что было добавлено в новом выпуске Java ?
Конечно, особое внимание было уделено производительности. Многие части виртуальной машины были оптимизированы и переписаны с использованием Assembler, а не C, как до этого. Кроме того, с октября 1996 года Sun развивает новый продукт - Just-In-Time компилятор, JIT . Его задача - транслировать Java байт-код программы в "родной" код операционной системы. Таким образом, время запуска программы увеличивается, но зато выполнение может ускоряться в некоторых случаях до 50 раз! С июля 1997 года появляется реализация под Windows и JIT стандартно входит в JDK с возможностью отключения.
Были добавлены многие новые важные возможности. JavaBeans - технология, объявленная еще в 1996 году, позволяет создавать визуальные компоненты, которые легко интегрируются в визуальные средства разработки. JDBC (Java DataBase Connectivity) обеспечивает доступ к базам данных. RMI (Remote Method Invocation) позволяет легко создавать распределенные приложения. Были усовершенствованы поддержка национальных языков и система безопасности .
За первые три недели JDK 1.1 был скачан более 220.000 раз, менее чем через год - более двух миллионов раз. На данный момент версия 1.1 считается полностью устаревшей и ее развитие остановилось на 1.1.8. Однако из-за того, что самый распространенный браузер MS IE до сих пор поддерживает только эту версию, она продолжает использоваться для написания небольших апплетов .
Кроме того, с 11 марта 1997 года компания Sun начала предлагать Java Runtime Environment , JRE (среду выполнения Java ). По сути дела, это минимальная реализация виртуальной машины, необходимая для исполнения Java -приложений, без компилятора и других средств разработки. Если пользователь хочет только запускать программы, это именно то, что ему нужно.
Как видно, самым главным недостатком осталась слабая поддержка графического интерфейса пользователя (GUI ). В декабре 1996 года компании Sun и Netscape объявляют новую библиотеку IFC (Internet Foundation Classes), разработанную Netscape полностью на Java и предназначенную как раз для создания сложного оконного интерфейса . В апреле 1997 года объявляется, что компании планируют объединить технологии AWT от Sun и IFC от Netscape для создания нового продукта Java Foundation Classes , JFC , в который должны войти:
- усовершенствованный оконный
Данный раздел состоит из шести частей. Обсуждаются вопросы безопасности распределенных вычислений в целом и рассматривается проблема защиты, связанная с исполняемым кодом. Предлагается шесть этапов для построения работоспособного и гибкого механизма безопасности. Также рассматривается реализация механизмов защиты в архитектуре языка Java. Как и во всякой новой технологии, имеются открытые вопросы, касающиеся безопасности в Java и до сих пор обсуждаемые в Сети и других форумах.
В данном разделе анализируется концепция безопасности в общем контексте взаимодействия в сети Web и реализация защиты посредством исполняемого кода.
Сначала рассмотрим двойственность вопроса безопасности в отношении сети Web и эволюцию сети Web как среды в контексте этой двойственности. Затем можно начинать описание проблемы защиты в контексте исполняемого кода.
Программа, полученная из сети, должна вызывать определенное доверие со стороны пользователя. Ей предоставляются некоторые ресурсы компьютера, иначе она не сможет выполнять никаких полезных действий. Однако эту программу писал некто, не имеющий никаких формальных обязательств перед пользователем. Если этот некто -- хакер, то полученный исполняемый код может быть потенциально опасной программой с теми же возможностями, что и локальная программа.
Должен ли пользователь полностью изолировать внешнюю программу от ресурсов компьютера? Конечно же, нет. В подобном случае исполняемый код не смог бы сделать ничего полезного. Более полное и эффективное решение проблемы безопасности можно разбить на шесть этапов:
1. Предугадать любые потенциально опасные действия и методы вторжения.
2. Свести любые опасные действия к минимальному набору простейших операций.
3. Построить среду программирования и компьютерный язык, явно запрещающие минимальный набор опасных операций, и, следовательно, любые злонамеренные действия.
4. Доказать логически или, если возможно, показать как очевидное тот факт, что язык и среда действительно защищены против методов преднамеренного вторжения.
5. Реализовать язык и разрешить исполняемым программам пользоваться только этим утвержденным безопасным языком.
Сценарии внешней атаки можно разбить на следующие группы (список не полный):
· Повреждение или нарушение целостности данных и/или состояния выполняемой программы;
· Сбор или копирование конфиденциальной информации;
· Блокирование ресурсов, вследствие которого они становятся недоступными для законных пользователей и программ;
· Захват ресурсов и их использование внешней неавторизованной программой;
· Создание нефатальных ситуаций, снижающих производительность, особенно в устройствах вывода;
· Присвоение прав доступа и использование их или компьютера клиента для вторжения в другие элементы сети.
В табл. 1.1 перечислены потенциально уязвимые ресурсы, а также типы воздействия, которые могут быть использованы по отношению к ним. В хорошей стратегии защиты каждому ресурсу назначается коэффициент риска и разрабатываются методы доступа к ним со стороны внешних исполняемых программ.
Таблица1.1 Потенциально уязвимые объекты и типы воздействие
|
Нарушение целостности |
Перехват информации |
Блокировка/ Изменение прав |
Захват ресурса |
Нефатальные помехи |
Захват полномочий |
|
|
Файловая система |
||||||
|
Нарушение целостности |
Перехват информации |
Блокировка/ Изменение прав |
Захват ресурса |
Нефатальные помехи |
Захват полномочий |
|
|
Конфиденциальная информация |
||||||
|
Центральный процессор |
||||||
|
Устройства вывода |
||||||
|
Устройства ввода |
||||||
|
ОС, состояние программ |
Вместо того чтобы рассматривать все возможные способы вмешательства, схема защиты в языке Java определяет уязвимые объекты основных потенциально опасных операций, что очень близко к описанному выше подходу.
Говоря конкретно, схема защиты языка Java рассматривает следующие уязвимые объекты:
· Память;
· ОС/состояние программ;
· Файловая система клиента;
· При этом учитываются следующие типы вмешательств, перечисленные в табл. 1.1;
· Нарушение целостности программ в клиентской машине. Обычно вызывается вирусами, которые записывают себя в память и разрушают определенные файлы при возникновении некоторого события или по достижении некоторой даты;
· Блокировка/изменение прав пользования ресурсами клиентской машины. Обычно вызывается вирусами;
· Перехват информации в клиентской машине. К примеру, легко выполняется при помощи команды UNIX SENDMAIL;
· Захват полномочий клиентской машины. Достигается подменой IP- адресов. Этот тип компьютерной атаки был придуман Кевином Митни- ком (Kevin Mitnick), когда тот "взломал" один из личных компьютеров эксперта по системам защиты Сутумо Шимура (Tsutumo Shimura). Весь этот инцидент подробно описан в бестселлере "Разборки", написанной для "New York Times" Сутумо Шимурой.
Первый уровень безопасности в Java -- это архитектура самого языка, синтаксические и семантические конструкции языка. Далее структура языка Java рассматривается с точки зрения безопасности.
Java -- полноценный объектно-ориентированный язык; каждая отдельная структура данных (и, следовательно, производная от нее) представляет собой настоящий полнофункциональный объект. То, что каждая примитивная структура данных оформлена как объект, гарантирует наличие всех теоретических преимуществ защиты ООП-языков в программах, написанных на Java, включая их синтаксис и семантику:
· Инкапсуляция и сокрытие данных в private-объявлениях;
· Управляемый доступ к структурам данных, при котором; используются только public-методы;
· Наращиваемость и иерархическое построение сложной структуры программы;
· Отсутствие перегрузки операций.
Классы и методы можно объявлять как final, запрещая тем самым создание подклассов и переопределение методов. Такое объявление препятствует злонамеренному изменению проверенного кода.
В целях безопасности преобразования типов (typecasting) проверяются как статически, так и динамически; это гарантирует то, что объявленный на этапе компиляции тип объекта будет точно соответствовать типу объекта во время выполнения, даже если по отношению к этому объекту выполнялись операции преобразования типов. Контроль за преобразованием типов препятствует преднамеренной подмене типов данных.
Вероятно, эта особенность, реализованная непосредственно в языке Java, является основной гарантией безопасности. Отсутствие указателей в Java- программе обеспечивает то, что все элементы данных всегда имеют имя. Каждая простая структура данных или фрагмент кода имеют идентификатор, позволяющий полностью контролировать их.
Java является многопотоковым языком и обеспечивает защищенный потоковый доступ к структурам данных и объектам. В главе 14 потоки Java рассматриваются подробно, приводятся примеры прикладных программ.
С каждым объектом в языке Java связан уникальный хэш-код (hashcode). Это означает, что в любой момент возможен мониторинг состояния Java- программы.
Во время компиляции анализируются все механизмы защиты, существующие в синтаксисе языка Java, включая проверку согласованности объявлений private и public, правильности типов и инициализации всех переменных в соответствии с предопределенными значениями.
Исходные классы Java компилируются в байт-коды. Верификатор байт- кодов выполняет множество проверок согласованности и безопасности компилированного кода. При верификации байт-кодов выполняются следующие операции:
· Проверка переполнения стека и потери значимости указателя стека;
· Анализ доступа к регистрам;
· Проверка правильности параметров байт-кодов;
· Анализ потоков байт-кодов, создаваемых методами, что обеспечивает целостность стека проверка получаемых объектов и объектов, возвращаемых методами.
Классы Java описываются внутри пакетов. Имена классов связаны с названиями пакетов. Пакеты гарантируют, что код, полученный из сети, отличается от локального кода. Принятая библиотека классов не может по ошибке или преднамеренно заменить локальные библиотеки проверенных классов или перехватить их права, даже если эти библиотеки имеют одинаковые имена. Это также защищает от непроверенных, случайных взаимодействий локального и принятого классов.
Позднее связывание гарантирует, что точное местоположение ресурсов на этапе выполнения происходит в самый последний момент. Позднее связывание представляет серьезное препятствие на пути внешних атак благодаря специальным соглашениям, касающимся выделения памяти для этих ресурсов.
По умолчанию механизм оперативной загрузки Java-ioiaccoB служит для выборки указанного класса из файла, расположенного в локальной хост-машине.
Любые другие способы загрузки классов, включая передачу по сети, требуют наличия соответствующего класса ClassLoader. ClassLoader -- это подкласс стандартного класса Java ClassLoader, имеющего методы, которые реализуют все механизмы проверки согласованности и защиты и запускаются для каждого вновь загружаемого класса.
Из соображений безопасности класс ClassLoader не может выполнять никаких опережающих действий в отношении байт-кодов. Байт-коды могут быть получены из Java-программы, транслируемой Java-компилятором или компилятором С++, модифицированным для создания байт-кодов. Это означает, что ClassLoader запускается только после проверки поступившего байт-кода; этот класс отвечает за создание пространства имен для загруженного кода и разрешение ссылок на имена классов, адресованных в полученном коде. При этом для каждого пакета создаются отдельные пространства имен.
В языках С и С++ программист явным образом распределяет память, освобождает ее и следит за всеми указателями на выделенную память. Зачастую это усложняет сопровождение программ и является главным источником ошибок, приводящих к появлению "висячих ссылок", вызванных использованием null-указателей и неправильными операциями выделения и освобождения памяти.
В языке Java указатели отсутствуют, поэтому программист не должен явно управлять памятью. Выделение и освобождение памяти выполняются автоматически, структурированно и с точным соблюдением согласования типов Для освобождения неиспользуемой памяти вместо явных программируемых операций применяется механизм сборки мусора (дефрагментация памяти). При этом устраняется возможность ошибок распределения памяти и потенциальные проблемы с безопасностью. При ручном выделении и освобождении памяти возможны нелегальные операции дублирования, клонирования и захват полномочий доступных объектов, а также нарушение целостности данных.
Класс SecurityManager является базовым, расширяемым средством для построения систем безопасности и обеспечения механизмов защиты для других компонентов языка Java, включая библиотеки классов и внешние среды (например, Java-совместимые браузеры и машинно-зависимые методы). Сам класс SecurityManager не предназначен для непосредственного использования (по умолчанию каждая из проверок вызывает некоторую исключительную ситуацию по защите); это базовый класс для создания подклассов, реализующих заданный набор методов защиты.
Помимо других особенностей в классе SecurityManager имеются методы для распознавания процессов проверки безопасности, а также методы для выполнения следующих проверок:
· Защита от инсталляции дополнительного загрузчиков классов ClassLoader;
· Возможность компоновки динамических библиотек (используется для машинно-зависимого кода);
· Чтение из файла классов а Запись в файл классов;
· Создание сетевого соединения;
· Возможность соединения с некоторым сетевым портом;
· Разрешение входящего сетевого соединения;
· Доступность некоторого пакета;
· Добавление в пакет нового класса.
Главным источником опасности для Java-nporpaMM является Java-код, поступающий из сети и выполняющийся на клиентском компьютере. Подобные транспортируемые Java-nporpaMMbi называются апплетами. Java-апплет имеет четко определенный набор возможностей и ограничений на уровне языка, особенно в части механизмов защиты.
На апплеты, загружаемые по сети, накладываются следующие ограничения:
· Нельзя создавать, переименовывать или копировать файлы и каталоги локальной файловой системы;
· Нельзя создавать произвольные сетевые соединения, за исключением связей с той хост-машиной, с которой апплеты были считаны. Имя хост- машины должно быть указано в URL-адресе той HTML-страницы, которая содержала тег
Перечисленные строгие ограничения на доступ к локальной файловой системе касаются апплетов, работающих в среде браузера Netscape Navigator 3.0. В программе Appletviewer из пакета JDK 1.0 ограничения менее строгие, и пользователь может определять явно список файлов, с которыми могут работать апплеты.
Апплеты могут считывать некоторые свойства системы при помощи вызова system.getProperty (string key). Апплеты в Netscape 3.0 имеют неограниченный доступ к этим свойствам. В программе JDK 1.0 Appletviewer от Sun можно индивидуально контролировать доступ к каждому свойству. В табл. 1.2 перечислена информация, возвращаемая для различных значений ключа key.
java интерфейс приложение программа
Таблица 1.2 Доступность системных переменных
В табл. 1.3 перечислены параметры, недоступные для апплетов в среде браузера Netscape 3.0. Программа JDK 1.0 Appletviewer и браузер HotJava позволяют пользователю управлять доступом к некоторым из указанных ресурсов.
Таблица 1.3 Системные переменные, недоступные для апплетов
Java-система загружает апплеты двумя способами. Апплет может быть передан по сети или же загружен из локальной файловой системы. Способ загрузки апплета определяет предоставляемые ему возможности.
С точки зрения безопасности, локальным апплетам разрешается выполнять следующие действия:
· Загружать в клиентской машине библиотеки;
· Выполнять в локальной машине внешние процессы;
· Останавливать работу виртуальной Java-машины.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Нижегородский государственный технический университет
Институт радиоэлектроники и информационных технологий
Кафедра «Информатика и системы управления»
Методы и средства защиты компьютерной информации
«Система безопасности Java»
Нижний Новгород, 2007
1. Принцип работы Java
2. Защита Java-аплетов
3. Модель безопасности JDK1.2
4. Криптографическая архитектура Java
5. Объектная организация механизмов безопасности
Список используемой литературы
1. Принцип работы Java
В основе технологии Java лежит клиент-серверная модель, а Java-программа состоит из нескольких блоков, каждый из которых выполняет определенную часть общей задачи. На стороне клиента присутствуют только те блоки, которые необходимы в данный момент. Причем наиболее часто используемые блоки хранятся в кэше на жестком диске или в оперативной памяти компьютера пользователя. Поскольку блок загружается с сервера, то и управлять такой системой можно с сервера, т. е. централизованно. Это также гарантирует, что пользователь всегда будет использовать самую последнюю версию программы.
Основной компонент этой технологии - виртуальный Java-процессор, который представляет собой среду для исполнения Java-команд, или так называемых байт-кодов. Любая Java-программа должна соответствовать спецификации виртуального Java-процессора, которая полностью определяет систему команд Java, типы данных, обрабатываемых Java-процессором, и его регистры.
Кроме виртуального процессора, технология Java включает в себя (в качестве необязательного элемента) объектно-ориентированный язык программирования, построенный на основе языка C++, к которому добавили новые механизмы для обеспечения безопасности и распределенных вычислений.
Особенностью Java являются аплеты. Аплет - это небольшая программка, в которой должно быть определено несколько обязательных функций. Аплет загружается по сети и может выполняться на Web-браузере, который поддерживает язык Java. Именно эта часть Java-технологии предназначена для использования во всемирной сети Internet, и поэтому защита должна распространяться как на сам аплет, так и на клиента сети, который использует этот аплет.
2. Защита Java -аплетов
Наиболее уязвимыми с точки зрения безопасности компонентом Java-технологии являются аплеты, поскольку их может использовать любой клиент. Именно поэтому для аплетов предусмотрены самые жесткие методы защиты. Хотя различные браузеры и программы просмотра аплетов могут по-разному защищать информацию пользователя от нападения, но в общем случае аплету должно быть запрещено следующее:
· проверять существование и параметры определенного файла;
· осуществлять доступ по сети к удаленному компьютеру;
· получать список сетевых сеансов связи, которые устанавливает локальный компьютер с другими компьютерами;
· получать сведения о пользователе или его домашней директории;
· выходить из интерпретатора Java;
Эти правила обеспечивают следующие компоненты Java-технологии.
· Собственно виртуальный Java-процессор, который постоянно контролирует свое состояние.
· Загрузчик аплетов и Java-программ, который контролирует загружаемые коды.
· Диспетчер безопасности (Secu-rityManager), контролирующий и блокирующий опасные действия аплетов.
В классе SecurityManager перечислены методы, которые используются системой для контроля действий аплета в зависимости от характеристик окружающей среды
Функция загрузчика - верификация байт-кодов, т. е. проверка правильности полученного элемента Java-программы и его целостности. В процессе верификации выясняется следующее:
· соответствует ли версия полученного блока версиям остальных элементов системы;
· соответствует ли программа спецификации конкретного виртуального Java-процессора;
Целями такой проверки являются выявление неправильного использования косвенной адресации, которое может привести к нарушению в работе виртуального процессора, и проверка целостности аплета.
Защитные механизмы этой технологии очень хорошо продуманы, но их реализация еще далека от совершенства. Поэтому далее приведен небольшой список возможных "нападений".
Блокировка сервиса
В результате этого частично или полностью блокируется работа пользователя и даже может быть выведен из строя браузер. Вот далеко не полный список возможных вариантов такого "нападения":
· заполнение всей свободной памяти;
· захват важных системных классов.
"Тайные" каналы
Эти каналы позволяют получать информацию даже через систему защиты (брандмауэры). Существование "тайных" каналов в браузере делает его очень опасным. В качестве "тайного" канала можно использовать следующие действия аплетов:
· посылку почты через SMTP-порт сервера (причем почта посылается от имени пользователя, который работает с аплетом);
· запрос на поиск по несуществующему URL-адресу, в котором в качестве параметров передаются необходимые "взломщику" данные;
· попытку доступа по несуществующему адресу (последовательность директорий может содержать необходимые данные).
Информация, известная аплетам
С помощью этой информации можно получить некоторые сведения, которые впоследствии могут быть им использованы для "взлома". Эту информацию можно передавать даже через брандмауэры по тайным каналам, которые описаны выше. Аплетам обычно известна следующая системная информация:
· системное время;
· название и версия операционной системы;
· архитектура процессора.
Установить баланс между возможностями загружаемых аплетов и защитой клиентской системы довольно сложно. Предлагаемые решения невозможно сделать независимыми от конкретной платформы, что противоречит требованию абсолютной переносимости Java-программ.
3. Модель безопасности JDK 1.2
В Java-технологии предусмотрен целый ряд защитных рубежей, которые можно разделить на три группы:
· надежность языка;
· контроль при получении и загрузке программ;
· контроль при выполнении программ.
Java обеспечивает безопасность за счет средств статического и динамического контроля. Еще одно Java -- автоматическое управление памятью, исключающее появление "висячих" указателей.
Контроль при получении и загрузке программ носит в Java многоступенчатый характер. Во-первых, программные компоненты могут снабжаться электронной подписью, что позволяет контролировать их целостность и аутентичность. Во-вторых, верификатор байт-кодов, кроме общей проверки формата поступившей информации, пытается убедиться в отсутствии следующих некорректных действий:
· подделка указателей (например, получение указателя как результат выполнения арифметической операции);
· нарушение прав доступа к компонентам классов;
· вызов методов объектов с недопустимым набором параметров;
· недопустимое преобразование типов;
· переполнение или исчерпание стека.
Контроль при выполнении программ можно разделить на два уровня. На нижнем уровне виртуальная Java-машина не допускает выходов за границы массивов и аналогичных некорректных действий. На верхнем уровне менеджер безопасности выполняет содержательные проверки правомерности доступа, реализуя тем самым выбранную политику безопасности.
Если продолжить деление на группы и уровни, то полезно выделить следующие два аспекта Java-безопасности:
· защита Java-окружения времени выполнения и ресурсов аппаратно-программной платформы от вредоносного программного обеспечения;
· разграничение доступа субъектов к ресурсам прикладного уровня.
Основная цель мер безопасности в Java -- обеспечить защиту Java-окружения от вредоносных программ. Для достижения этой цели была предложена концепция "песочницы" (sandbox ) -- замкнутой среды, в которой выполняются потенциально ненадежные программы. Таковыми считались аплеты, поступившие по сети. Весь "родной" код (то есть программы, располагающиеся на локальном компьютере) считался абсолютно надежным и ему было доступно все, что доступно виртуальной Java-машине.
В число ограничений, налагаемых "песочницей", входит запрет на доступ к локальной файловой системе, на сетевое взаимодействие со всеми хостами, кроме источника аплета (хост, с которого аплет был получен) и т.д. При таких ограничениях безопасность в общем и целом обеспечивается, но возможности для работы у аплетов почти не остается.
Чтобы как-то справиться с этой проблемой, ввели понятие электронной подписи, которую ставит распространитель аплета. Java-машина в соответствии со своей политикой безопасности делит распространителей и, соответственно, их аплеты на две категории -- надежные и ненадежные. Надежные аплеты были приравнены в правах к "родному" коду.
Оформились три основных понятия:
· источник программы;
· право и множество прав;
· политика безопасности.
Источник программы определяется парой (универсальный локатор ресурсов -- URL, распространители программы). URL может указывать на файл в локальной файловой системе или же на ресурс удаленной системы.
Право -- это абстрактное понятие, за которым, как обычно в Java, стоят классы и объекты. В большинстве случаев право определяется двумя цепочками символов -- именем ресурса и действием. Например, в качестве ресурса может выступать файл, а в качестве действия -- чтение.
Политика безопасности задает соответствие между источником и правами поступивших из него программ. "Родные" программы не имеют каких-либо привилегий в плане безопасности и политика по отношению к ним может быть любой.
По сути имеется традиционный для современных операционных систем и систем управления базами данных механизм прав доступа со следующими особенностями:
· Субъектом доступа является не пользователь, а источник программы. Впрочем, формально можно считать, что во время исполнения программы ее источник становится;
· Нет понятия владельца ресурса, который (владелец) мог бы менять права; последние задаются исключительно политикой безопасности.
Модель безопасности в JDK 1.2
4. Криптографическая архитектура Java
Без криптографии невозможны надежная аутентификация, контроль целостности и сохранение конфиденциальности.
Криптографическая архитектура Java (Java Cryptography Architecture, JCA) разработана для предоставления следующих сервисов:
· постановка/проверка электронной подписи;
· вычисление хэш-функции;
· генерация пар ключей открытый/секретный;
· создание сертификатов, подтверждающих аутентичность открытых ключей;
· хранение ключей, а также сертификатов надежных партнеров;
· преобразование ключей из представления со скрытой структурой в общепонятное представление и наоборот;
· генерация параметров криптографических алгоритмов;
· генерация (псевдо)случайных чисел;
· симметричное шифрование;
· выработка общего ключевого материала.
Кроме того, криптографическая архитектура должна удовлетворять следующим технологическим требованиям:
· обеспечивать независимость от алгоритмов и их реализаций;
· обеспечивать взаимную совместимость реализаций;
· обеспечивать расширяемость набора алгоритмов и их реализаций.
Каждый сервис может обеспечиваться несколькими алгоритмами, каждый из которых, в свою очередь, может иметь несколько реализаций. Например, для вычисления хэш-функции предназначены алгоритмы MD5/SHA-1 (равно как и российский ГОСТ "Функция хэширования"), для выработки и проверки электронной подписи -- алгоритмы RSA/DSA, российский ГОСТ "Процедуры выработки и проверки электронной цифровой подписи" и т.д.
Программный интерфейс сервисов построен так, чтобы отразить их функциональность в алгоритмически-независимой форме. Для обозначения реализаций используется понятие поставщика криптографических услуг -- пакета или группы пакетов, содержащих реализацию. Приложение имеет возможность выбирать алгоритмы и поставщиков услуг из числа доступных.
Два последних элемента в списке сервисов (симметричное шифрование и выработка общего ключевого материала) подвержены экспортным ограничениям США, поэтому они, в отличие от остальных перечисленных сервисов, оформлены как расширение (Java Cryptography Extension, JCE), являющееся отдельным продуктом.
Иерархия криптографических сервисов, алгоритмов и реализаций
5. Объектная орга низация механизмов безопасности
java аплет защита криптографический
Механизмы безопасности в JDK 1.2 оформлены в виде четырех основных пакетов и трех пакетов расширения. Вот некоторые из них
· java.security -- содержит интерфейсы и классы, составляющие каркас механизмов безопасности. Сюда входят рассмотренные выше средства разграничения доступа, а также криптографические средства, такие как выработка электронной подписи, вычисление хэш-функции и т.п.
· java.security.interfaces -- средства генерации RSA- и DSA-ключей.
· javax.crypto -- интерфейс и классы для симметричного шифрования.
Наиболее важные с концептуальной точки зрения интерфейсы и классы сосредоточены в пакете java.security .
Политика безопасности
Политика безопасности в устанавливает соответствие между источниками программ и их правами доступа. В Java-машине в каждый момент времени она представлена одним объектом класса, являющегося преемником абстрактного класса Policy . Методы класса Policy позволяют получить/установить текущую политику, а также выяснить права доступа, ассоциированные с заданным источником программ.
Проверка прав доступа
Для контроля прав доступа можно пользоваться двумя средствами:
· встроенным менеджером безопасности, получившим название AccessController ;
· динамически изменяемым менеджером безопасности -- SecurityManager .
Класс AccessController предоставляет единый метод для проверки заданного права в текущем контексте -- checkPermission.
Криптографические интерфейсы и классы
Объектная организация криптографической подсистемы Java естественным образом отражает описанную выше криптографическую. Каждому сервису соответствует абстрактный класс, описывающий его (сервиса) программный интерфейс, а также класс, описывающий программный интерфейс поставщика сервиса. Важными являются классы Provider и Security . В первом собраны общие методы поставщиков криптографических услуг, во втором -- методы управления поставщиками и параметрами алгоритмов.
Список используемой литературы
1. http://www.jetinfo.ru/1998/11-12/1/article1.11-12.19981237.html
2. http://vestnik.sci.pfu.edu.ru/archiv-cs/articles-cs/2004-3-1/pdf/kulyabov-2004.pdf
3. http://ru.wikipedia.org/wiki/Java
4. http://infocity.kiev.ua/hack/content/hack081.phtml
5. http://citforum.uar.net/security/web/java_seq.shtml
6. http://www.htc-cs.ru/press/tribune/java.html
7. http://www.ccc.ru/magazine/depot/00_11/print.html?web3.htm
Размещено на Allbest.ru
Подобные документы
Архитектура Java и Java RMI, их основные свойства, базовая система и элементы. Безопасность и виртуальная Java-машина. Интерфейс Java API. Пример использования приложения RMI. Работа с программой "Calculator". Универсальность, портативность платформ.
курсовая работа , добавлен 03.12.2013
Понятие и функциональные особенности Java Card как версии Java-платформы для устройств с крайне ограниченными вычислительными ресурсами, оценка ее возможностей и необходимых ресурсов. Анализ степени безопасности платформы, взаимодействие компонентов.
презентация , добавлен 19.05.2014
Сетевые возможности языков программирования. Преимущества использования Java-апплетов. Классы, входящие в состав библиотеки java.awt. Создание пользовательского интерфейса. Сокетное соединение с сервером. Графика в Java. Значения составляющих цвета.
курсовая работа , добавлен 10.11.2014
История создания языка Java. Основные принципы объектно-ориентированного программирования. Структура, особенности синтаксиса и примеры прикладных возможностей использования языка Java, его преимущества. Перспективы работы программистом на языке Java.
курсовая работа , добавлен 14.12.2012
Основа пользовательского интерфейса. Возможности пакетов java.awt.geom, java.awt, классов java.awt.Graphics и java.awt.Graphics2D. Основные графические примитивы и работа с потоками. Листинг программы и составление композиции аффинных преобразований.
методичка , добавлен 30.06.2009
Архитектура уровня команд платформы Java, формат файла класса Java. Компилятор ассемблероподобного языка, позволяющий создавать файлы классов, корректно обрабатываемые реальной JVM, поддерживающий все команды байт-кода Java и важнейшие возможности JVM.
курсовая работа , добавлен 17.09.2008
Кратка историческая справка развития языка Java. Анализ предметной области. Java platform, enterprise and standart edition. Апплеты, сервлеты, gui-приложения. Розработка программного кода, консольное приложение. Результаты работы апплета, сервлета.
курсовая работа , добавлен 23.12.2015
Преимущество использования программ, написанных на Java, требования к ним и настройки на клиентском ПК. Развертывание и последующее "автоматическое" обновление версий GUI клиента с помощью использования технологии Java Web Start в среде Windows.
реферат , добавлен 16.05.2011
Создание языка программирования с помощью приложения "Java". История названия и эмблемы Java. Обзор многообразия современных текстовых редакторов. Обработка строки. Методы в классе String. Java: задачи по обработке текста. Примеры программирования.
курсовая работа , добавлен 19.07.2014
Расширяемый язык разметки XML. Описание типа документа DTD. Значение XML и платформы Java. Обзор стандартных анализаторов DOM и SAX. Технология Java Servlet, Java Server Pages (JSP), JavaBeans. Общая функциональность программного продукта. Модель данных.
Язык программирования Java и сопровождающая его система поддержки исполнения программ были разработаны для того, чтобы однажды разработанные и скомпилированные программы поставлялись через Интернет в двоичном виде и работали на любой машине, поддерживающей Java. Безопасность стала частью разработки Java с самого начала. В данном разделе будет рассмотрена работа этой системы безопасности.
Java является языком, обеспечивающим безопасность при работе с типами. Это означает, что компилятор отклонит любую попытку использовать переменную таким
 |
местим с ее типом. Для сравнения рассмотрим следующий
Он генерирует случайное число и сохраняет его в указателе р. Затем он сохраняет нулевой байт по адресу, содержащемуся в р, переписывая то, что было там до этого, - код или данные. В Java конструкции, в которых подобным образом смешиваются типы, запрещены самой грамматикой. Кроме того, в Java нет переменных-указателей, привидения типов, распределения памяти, управляемого пользователем (например, с помощью malloc и free), а все ссылки на массивы проверяются в ходе выполнения.
Java-программы компилируются в промежуточный двоичный код, называемый байткодом JVM. В JVM есть около 100 команд, большинство из которых помещают объекты определенного типа в стек, извлекают их из стека или арифметически объединяют две записи в стеке. Эти JVM-программы, как правило, интерпретируются, хотя в некото
рых случаях они могут быть скомпилированы в машинный язык для более быстрого исполнения. В модели Java апплеты, отправляемые через Интернет для удаленного исполнения, являются JVM-программами.
При поступлении апплета он попускается через процедуру проверки байт-кода JVM на предмет соответствия определенным правилам. Правильно откомпилированный апплет будет соответствовать им автоматически, но ничто не мешает злоумышленникам написать JVM-апплет на языке ассемблера JVM. Процедура проверки включает в себя поиск ответов на следующие вопросы:
1. Не пытается ли апплет подделать указатели?
2. Не нарушает ли он ограничения доступа к элементам закрытых классов?
3. Не пытается ли он использовать переменную одного типа как переменную другого типа?
4. Не генерирует ли он переполнение стека или выход за его нижние границы?
5. Не совершает ли он недопустимые преобразования переменных одного типа в переменные другого типа?
Если апплет проходит все эти тесты, он может быть запущен без опасений, что он будет обращаться не к своим областям памяти.
Тем не менее апплеты все же могут выполнять системные вызовы за счет вызова Java- методов (процедур), предоставляемых для этих целей. Способы, которые использовались для этого в Java, все время совершенствовались. В первой версии Java, JDK (Java Development Kit - инструментарий Java-разработчика) 1.0, апплеты подразделялись на два класса: надежные и ненадежные. Апплеты, получаемые с локального диска, были надежными и им разрешалось выполнять любой необходимый им системный вызов. В отличие от них апплеты, получаемые через Интернет, считались ненадежными. Они запускались в песочнице, как показано на рис. 9.33, и им практически ничего не разрешалось делать.
Набравшись опыта использования этой модели, компания Sun решила, что она имеет слишком ограничивающий характер. В JDK 1.1 была задействована цифровая подпись кода. Когда апплет поступал из Интернета, проводилась проверка, был он подписан человеком или организацией, которой пользователь доверяет (что определялось пользовательским списком доверенных владельцев цифровых подписей). Если подписи можно было доверять, апплет мог делать все что угодно, если нет, - он запускался в песочнице со строгими ограничениями.
После приобретения дополнительного опыта эта система также была признана неудовлетворительной, поэтому модель безопасности опять претерпела изменения. В JDK 1.2 была представлена конфигурируемая, тонко настраиваемая политика безопасности, применяемая ко всем апплетам, как локальным, так и удаленным. Эта модель безопасности настолько сложна, что ее описанию следует посвятить отдельную книгу (Gong, 1999), поэтому мы дадим лишь краткую обобщенную картину некоторых ее основных особенностей. Каждый апплет характеризуется двумя вещами: тем, откуда он прибыл и тем, кто его подписал. На вопрос, откуда он прибыл, отвечает его URL, а на вопрос, кто его подписал, отвечает закрытый ключ, который был использован для его цифровой подписи. Каждый пользователь может создать политику безопасности, состоящую из перечня правил. В каждом правиле могут перечисляться URL, владелец подписи, объект и действие, которое апплет может совершить с объектом, если URL апплета
и владелец подписи совпадут с указанными в правиле. Концептуально предоставляемая информация показана в табл. 9.3, хотя реально она отформатирована по-другому и имеет отношение к иерархии классов Java.
Один вид действий разрешает доступ к файлу. Действие может определять конкретный файл или каталог, набор всех файлов в заданном каталоге или набор всех файлов и каталогов, рекурсивно содержащихся в заданном каталоге. Три строки в табл. 9.3 соответствуют этим трем случаям. В первой строке пользователь Сьюзен установила свою запись прав доступа так, что апплеты, поступающие от машины обработчика ее налоговых данных, которая называется www.taxprep.com, и подписанные компанией- обработчиком, имеют доступ для чтения к ее налоговым данным в файле 1040.xls. Они могут читать только этот файл, который не могут читать никакие другие апплеты. Кроме того, все апплеты из всех источников независимо от того, подписаны они или нет, могут читать и записывать файлы в каталоге /usr/tmp.
Далее, Сьюзен доверяет корпорации Microsoft настолько, что разрешает апплетам, получаемым с ее сайта и подписанным этой компанией, читать, записывать и удалять файлы, находящихся ниже каталога Office в дереве каталогов, к примеру, для устранения дефектов и установки новых версий программного обеспечения. Для проверки подписей Сьюзен либо должна иметь необходимый открытый ключ на своем диске, либо должна получать их в динамическом режиме, например в виде сертификата, подписанного компанией, которой она доверяет и чей открытый ключ у нее имеется.
В качестве защищаемых ресурсов могут выступать не только файлы. Можно также защитить доступ к сети. Здесь объектом будет конкретный порт на конкретном компьютере. Компьютер указывается с помощью IP-адреса или DNS-имени; порты на этом компьютере указываются диапазоном чисел. Возможные действия включают в себя подключение к удаленному компьютеру и прием подключений, исходящих от удаленного компьютера. Таким образом, апплет может получить доступ к сети, но этот доступ ограничен обменом данными только с теми компьютерами, которые явным образом перечислены в списке разрешений. Апплеты могут в случае необходимости динамически загружать дополнительный код (классы), но предоставляемые пользователем загрузчики классов могут осуществлять строгий контроль того, какие машины могут быть источниками этих классов. Существует также множество других средств безопасности.
Еще по теме Безопасность в системе Java:
- § 39 Классификация договоров в отдельных видах. – Римская классификация. – Система прусского закона, французского и австрийского кодекса. – Система русского свода. – Система настоящего изложения.
Что такое информационная безопасность? Это состояние защищенности информации, при котором обеспечиваются её конфиденциальность, доступность и целостность.
Обычно для того, чтобы оценить состояние защищенности информации, необходимо понять и провести анализ угроз и их источников, оценить уровень ущерба, вероятность реализации и актуальность угроз, риски (опционально), которые могут воздействовать на нашу систему/информацию.
На мой взгляд, невозможно оценить безопасность отдельно взятой технологии или языка программирования без привязки к конкретному способу реализации, т. е. без конкретного готового программного продукта на языке, у которого есть детальное ТЗ с описанием архитектуры и функционала. Но и этого тоже будет мало, так как необходимо оценивать состояние защищенности готовой информационной системы со своей специфичной архитектурой, набором компонентов, бизнес-процессами, информацией и, наконец, людьми. Приведу пример с постройкой дома. У нас есть материалы (песок, цемент, щебень, кирпич и т. д.) и инструменты (ведро, лопата, шпатель и т. п.). Оценить исключительно по используемым материалам/инструментам качество и надежность готового дома мы не сможем: сколько он простоит, будут ли в нем трещины, будет ли в нем холодно или тихо. Нужно выбрать проект дома, технологии строительства и бригаду мастеров. И только после завершения строительства мы сможем провести измерения соответствия проекту, ГОСТу, СНиПам, проверить измерения по теплозащите, шуму, нагрузкам, провести анализ качества цемента и ответить на большинство вопросов. Но на главный вопрос «сколько он простоит?» у нас не будет точного ответа, так как мы не знаем всех условий эксплуатации дома и всех факторов, которые будут воздействовать на протяжении всего времени.
Как обеспечить безопасность в Java
Возьмем к примеру Java. Это объектно-ориентированный язык программирования; программы, написанные на Java, транслируются в байт-код Java, выполняемый виртуальной машиной Java (JVM) - программой, обрабатывающей байтовый код и передающей инструкции оборудованию как интерпретатор. Достоинством подобного способа выполнения программ является полная независимость байт-кода от операционной системы и оборудования, что позволяет выполнять Java-приложения на любом устройстве, для которого существует соответствующая виртуальная машина.
« Универсальный язык» звучит красиво, но самая распространённая проблема - это одновременно и обратная сторона медали - утечка памяти в JVM, что приводит к переполнению памяти и сбоям. В связи с этой проблемой не исключены уязвимости, ведь основной постулат надежности - чем проще, тем лучше. В данном же случае собирается такой сложный пирог из обеспечения совместимости большого количества платформ и ОС, что практически невозможно отслеживать и закрывать все найденные в них уязвимости и оперативно их устранять. У той же Microsoft уязвимости могут быть найдены и исправлены спустя 4-8 лет, и это если не брать в расчёт оставленные намеренно или по ошибке недекларированные возможности.
Из моей практики: когда программисты добавляют новый функционал, который связан с уже реализованным, или исправляют старый функционал, то в 15% случаях они ломают ранее работающий продукт. И если при этом не проводят полное тестирование - на выходе имеем продукт с новым функционалом, но с частично не работающим старым. Также существуют различия написания кода для разных платформ, версий ОС, ПО. В связи с этим можно себе представить, насколько тяжело поддерживать язык программирования Javа и JVM, не говоря уже про вопросы безопасности.
На текущий момент выпущен Java Development Kit 10, который предлагает нам штатные механизмы обеспечения безопасности, выпущенные еще для Java SE 8 и описанные в Security Documentation. В десятой версии не добавилось ничего нового.
Отмечу, что у Oracle существует ресурсный центр безопасности Java . В целом компания разделяет безопасность Java на четыре основных раздела:
А) разработчики должны:
Следить и использовать все последние обновления среды разработки и безопасности;
Использовать программы контроля корректности кода (например, Checker Framework);
Б) системные администраторы должны:
Следить и использовать все последние обновления для Java и необходимые компоненты для работы продукта (в т. ч. ОС, библиотеки, фреймворки, и т. д.);
Использовать правила развертывания Java, описанные и ;
Использовать надёжную метку времени.
В) конечные пользователи должны:
Всегда использовать последнюю оригинальную версию Java;
Г) профессионалам в области безопасности необходимо:
Использовать расширенные инструменты управления и повышения безопасности (например, Advanced Management Console);
Контролировать своевременную установку всех обновлений безопасности;
Важно, чтобы все следовали и выполняли правила и требования безопасности. Достичь состояния безопасности на адекватном уровне можно только сообща и применяя все доступные меры (технические, организационные). Как показывает моя практика, в 60% организаций у ИТ- и ИБ-служб все нормально с безопасностью, а также с пользователями, которые используют корпоративные устройства и подключены к единому домену. А вот самыми неконтролируемыми в этой области являются разработчики, тимлиды, архитекторы.
Разработка ПО и вопросы безопасности
Если взять шире, то основные причины возникновения проблем безопасности в приложениях при разработке ПО следующие:
А) Отсутствие понимания терминологии безопасности в целом, не говоря о специфических знаниях и применяемых решениях.
Как правило, у разработчиков безопасность в лучшем случае ассоциируется со следующими вещами: управление и журналирование доступа и парольная защита, реже - защита соединения на уровне https (использование механизмов шифрования, которые доступны из коробки по умолчанию). Т. е. формально они будут использовать методы обеспечения безопасности, которые по факту останутся формальными, «для галочки», без учета требований и нюансов:
Для паролей: обычно используются значения по умолчанию и не настраиваются дополнительно длина, стойкость, частота смены, неповторяемость, количество попыток. Довольно часто эти параметры нельзя донастроить, так как они не были включены в скоуп-задачу по разработке ПО, что приводит к необходимости дописывать код.
По управлению и журналированию доступа: в лучшем случае разработчикам описали группы или роли пользователей и объекты доступа, которые должны быть доступны в ПО. В худшем - разработчики сами «поделили» разделы и объекты на необходимые пользователям и администраторам. В первом случае получаем систему, которую можно гибко настроить, но требуется потратить значительное количество времени на настройку и согласование прав. Во втором - формальную систему разграничения доступа. Кроме того, разработчикам надо понимать, какую именно информацию и в каком объёме необходимо журналировать. Однако зачастую им эту информацию не предоставляют, что приводит к недостаточной детализации журналов для разбора инцидентов или понимания того, что происходит в ПО. Или же к избыточному хранению логов и большого объёма информации, что накладывает существенные ограничения на возможность хранения информации в течение необходимого периода времени (например, один-три года) или возникает необходимость закупки дополнительных хранилищ информации. При избыточной записи информации возникают дополнительные проблемы со скоростью анализа и разбора инцидентов и быстротой поиска нужной информации. Избыточность также может потребовать дополнительного финансирования на расширение штата, закупку SIEM-систем с настройкой уникальных правил обработки информации или вести к рискам, связанным с неактуальностью информации. При этом тратится слишком много времени на анализ и обработку информации.
Защита каналов связи - не менее существенный момент, особенно для платежных и банковских систем, где помимо разглашения персональных и личных данных возможны финансовые потери. Чаще всего бывает, что о защите каналов и среды передачи информации не думают, а если и думают, то используют настройки «по умолчанию», например, TLS/SSL. Но там ведь тоже есть свои особенности по выбору версии протокола (TLS 1.1, 1.2, 1.3 или SSL v1-3), алгоритма шифрования (RC4, IDEA, Triple DES, SEED, Camellia или AES), длины ключа. Иногда выбирается, например, правильный протокол TLS 1.2, с шифрованием по AES, длиной ключа 256 бит, но забывается про возможность выбора адреса по порту 443 для HTTPS и или 80-й порт для HTTP, вместо блокировки 80-го порта, в результате чего появляется возможность получать доступ по незащищенному каналу. Или, например, поднимают инфраструктуру на виртуальных машинах и совсем не думают о необходимости закрыть сетевой доступ между виртуальными машинами.
Б) Вторая проблема связана с бизнесом, так как он вкладывает деньги в конкретный специальный функционал, который не учитывает блоки безопасности.
К сожалению, бизнес не всегда понимает, зачем ему тратить ресурсы на блоки безопасности, если от них нет функциональной пользы, денег больше продукт не принесёт, а есть только вероятные риски, которые могут и не сработать. Бизнес чаще понимает необходимость вкладываться в безопасность, когда инцидент ИБ уже произошел.
К сожалению, в этом виноват не только бизнес, но и его окружение, которое:
Также не понимает в безопасности;
Пожалело бюджет на специалистов по ИБ (не нанимаются вообще или нанимаются узкоспециализированные специалисты, или нанимается один человек, отвечающий за все);
Не смогло аргументировано донести необходимость в безопасности и правильно обосновать текущие риски (репутационные, финансовые, временны́е).
В) Проблема с коммуникацией в компании или отсутствие оной.
Это тот случай, когда бизнес и его окружение понимают необходимость и важность ИБ. Они выделили бюджеты, наняли соответствующих специалистов, но возникают сложности в коммуникации между бизнес-подразделениями и службами ИБ/ИТ, разработчиками.
Г) Недостаточная осведомленность простых пользователей компании в вопросах ИБ.
Предположим, что есть все необходимые подразделения, специалисты, технические и организационные меры. Но пользователи упираются и не хотят работать по правилам. Очень частая ситуация, и решать ее также необходимо комплексно, так как люди не понимают, зачем им лишняя работа по соблюдению вопросов ИБ (проверять файлы антивирусом, запоминать сложные пароли, знать и соблюдать политики и бизнес-процессы и т. д.). Нужно периодически устраивать мастер-классы, рассказывать на бытовом уровне, что такое ИБ, какие есть проблемы и решения, доводить глобальные цели и задачи ИБ, их и влияние на бизнес, мотивировать.
Д) Нехватка архитекторов ИБ - не всегда в разработке ПО участвуют специалисты по ИБ, и программисты сами думают о безопасности архитектуры и применении написанных и готовых шаблонов безопасности (Security patterns).
Всех нюансов разработчики не знают и не могут знать, так как их задача - выполнить разработку и перейти к следующей. Если углубиться в саму разработку, то процесс намного сложнее, чем кажется. Поэтому необходимо четко получить задачу от бизнеса, декомпозировать ее на понятные мини-задачи для разработчиков, провести разработку, провести альфа- и бета-тестирования, нагрузочные, функциональные тестирования, исправить ошибки, вернуться к тестам - этот процесс цикличный и долгий. Поэтому неудивительно, что у них не хватает ресурсов продумать до мелочей безопасность продукта.
Чтобы можно было говорить о безопасности, нужно решить описанные выше проблемы. Я специально не описываю варианты решений, так как все зависит от конкретных проблем, среды, условий. Универсальной пилюли не существует и необходимо использовать все возможные меры. Основная задача состоит в том, чтобы все работники компании вникали, понимали и выполняли требования ИБ и были заинтересованы в их соблюдении. И только тогда можно будет говорить об эффективности и хорошем уровне зрелости ИБ в компании.