Почему я должен подписывать файлы JAR?
Почему я должен подписывать свои файлы JAR?
Я знаю, что мне нужно подписать файлы JAR на стороне клиента (содержащие апплеты), чтобы можно было сделать специальные вещи, такие как доступ к файловой системе, и чтобы раздражающий бит внизу окон не отображался, но почему еще? И мне нужно подписать мои файлы JAR на стороне сервера, содержащие сервлеты и т. д.?
некоторые основные правила для того, когда и когда не подписывать банки будут оценены-спасибо!
4 ответов
короткий ответ - нет, если политика компании заставляет вас.
долгий ответ
Подписание банок эффективно говорит вашему клиенту: "я сделал это, и я гарантирую, что это не испортит вашу систему. Если да, то приходите ко мне за возмездием". Вот почему подписанные банки в клиентском решении, развернутом с удаленных серверов (апплеты / webstart), имеют более высокие привилегии, чем не подписанные решения.
на серверных решениях, где вам не нужно умиротворите требования безопасности JVM, эта гарантия только для вашего душевного спокойствия клиента.
Плохо, что подписанные банки загружаются медленнее, чем неподписанные. Насколько медленнее? это ЦП, но я заметил, более чем 100% увеличение времени загрузки. Кроме того, патчи сложнее (вы должны повторно подписать банку), патчи классов невозможны (все классы в одном пакете должны иметь один и тот же источник подписи), и разделение банок становится рутиной. Не говоря уже о процессе сборки дольше, и что правильные сертификаты стоят денег (самоподписанные почти бесполезны).
Итак, если ваша политика компании не заставляет вас, не подписывайте jars на стороне сервера и храните общие jars в подписанных и не подписанных версиях (подписанный переход к развертыванию на стороне клиента, не подписанный переход к серверной кодовой базе).
хорошей причиной может быть, если вы никогда не хотели, чтобы кто-то мог проникнуть в модифицированные классы, которые будут вызываться вашим кодом.
к сожалению, это включает в себя :-D Так что это нужно сделать, только если вам это действительно нужно. Проверьте концепцию "запечатанной банки".
с точки зрения апплетов: от 6u10 Sun JRE заменяет предупреждающий баннер менее навязчивым (от 6u12, IIRC) предупреждающим треугольником (необходимым для поддержки фигурных и прозрачных окон). 6u10 также позволяет контролировать доступ к файлам через API служб JNLP.
принцип наименьших привилегий гласит, что вы не должны подписывать классы ваших файлов jar. Безопасность не всегда проста.
простое отображение диалогового окна сертификата не должно толковаться как означающее что все содержимое веб-страницы можно доверять.
подписание файла jar, как и использование сертификатов в других контекстах, делается так, чтобы люди, использующие его, знали, откуда он пришел. Люди могут верить, что Крис Каррутерс не собирается писать вредоносный код, и поэтому они готовы разрешить вашему апплету доступ к своей файловой системе. Подпись дает им некоторую гарантию, что Банка действительно была создана вами, а не самозванцем или кем-то, кому они не доверяют.
в случае серверных или библиотечных банок обычно нет нужно предоставить такую гарантию кому угодно. Если это ваш сервер, то вы знаете, какие банки вы используете и откуда они пришли, и вы, вероятно, доверяете своему собственному коду, чтобы не быть злонамеренным.